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STUDY  RESULTS 


This  report  presents  the  results  of  a  study  to  develop 
"Criteria  for  Centralized  Control  of  Army-Wide  Management 
Information  Systems,"  performed  by  Peat,  Marwick,  Livingston 
&  Co.  (PML)  under  contract  number  DAHC  19-67-C-0052 .  The 
study  was  conducted  on  behalf  of  the  Management  Information 
Systems  Directorate  (MISD)  within  the  Department  of  Army, 
Office  of  the  Assistant  Vice  Chief  of  Staff,  as  part  of 
a  continuing  effort  to  improve  the  management  of  informa¬ 
tion  systems  within  the  Army.  The  principal  reasons  for 
the  study  were  the  Army's  growing  dependence  on  accurate 
and  timely  information  on  which  to  base  management  deci¬ 
sions  and  the  increasing  cost  and  complexity  of  the  systems 
that  provide  this  information. 

Approach 

PML's  initial  work  consisted  of  an  analysis  of  the 
structure  of  Army  Management  Information  Systems.  This 
was  followed  by  the  development  of  techniques,  criteria, 
and  capabilities  for  the  Army's  use  in  more  effectively 
managing  and  developing  these  systems.  The  major  tasks 
performed  were: 

.  description  of  Army  management  information 
structure: 

.  identification  of  resources  and  system  ele¬ 
ments  whose  management  is  vital  to  the 
success  of  all  management  information  systems 
and  improvement  projects; 

.  definition  >£  the  management  information 
system  life  cycle; 

.  design  of  a  management  control  system  to 
support  the  mission  of  the  Management  Infor¬ 
mation  Systems  Directorate; 

.  development  of  criteria  and  methodology  for 
evaluating  and  controlling  management  infor¬ 
mation  systems  and  improvement  projects;  and 

.  assistance  to  the  Army  in  writing  directives 
to  promulgate  policies  and  procedures  for 
management  information  systems. 


1 .1 


‘ —  /t'lf  I tir+ni  f  «.  — ... 


Problem  Areas 


Peat,  Marwick,  Livingston  &  Co.'s  study  of  the  man¬ 
agement  situation  at  MISD  resulted  in  the  identification 
of  a  number  of  basic  problem  areas.  It  is  PML's  belief 
that  the  Army's  system  management  capabilities  will 
improve  as  these  problems  and  their  causes  are  removed. 

In  several  instances,  efforts  have  already  begun  to 
correct  or  improve  the  situations.  The  four  major  problem 
areas  identified  by  PML  are  described  in  the  following 
paragraphs . 

MISD  lacks  the  information  and  methodology  needed 
to  provide  an  overview  of  the  Army  Management  Information 
System  (AMIS)  and  to  manage  AMIS  component  systems.  This  in 
turn  makes  it  impossible  for  MISD  to  be  aware  of  the  over¬ 
all  direction  and  costs  of  the  systems  for  which  it  is 
responsible.  This  is  true  for  both  operations  and  develop¬ 
ment  activities.  The  deficiency  also  lowers  the  quality 
cf  cost  estimates  and  the  ability  of  MISD  to  evaluate  pro¬ 
posals  for  new  systems. 

Information  system  activities  have  not  yet  been  related 
to  the  Army's  Planning-Programming-Budgeting  System.  Their 
lack  of  financial  visibility  prevents  the  structuring  of  a 
funding  base  for  information  systems.  The  deficiencies  of 
formal  procedures  and  guidance  aids  hinder  MISD  in  meeting 
the  complex  needs  of  funding  individual  development  projects. 
Some  of  these  projects  lack  the  financial  basis  necessary 
for  successful  completion,  but  the  deficiencies  of  proce¬ 
dures  and  guidance  aids  prevent  the  detection  of  this  con¬ 
dition  early  in  the  project's  life  cycle. 

Finally,  there  are  no  procedures  for  comparing  the  con¬ 
tributions  of  various  information  systems,  for  establishing 
requirements  and  resource  priorities,  or  for  broad  planning 
beyond  the  immediate  future.  Because  of  this  procedural 
void,  the  impact  of  proposed  projects  on  existing  systems 
and  projects  cannot  be  consistently  assessed.  Since  the 
proposed  projects  are  competing  for  resources,  the  inability 
to  consistently  assess  their  impact  makes  it  impossible 
for  MISD  to  lllocate  resources  (e.g.,  programmers)  effi¬ 
ciently.  Furtnermorc,  since  project  planning  and  control 
arc  not  uniformly  accomplished,  adequate  evaluation  data 
is  not  available. 

A  second  major  problem  faced  by  MISD  is  the  lack  of 
information  and  methodology  needed  to  adequately  evaluate 
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improvement  proposals  and  manage  improvement  projects. 

The  Army  does  not  utilize  a  uniform  approach  in  develop¬ 
ing  its  management  information  systems.  Specific  develop¬ 
mental  approval  procedures  have  not  been  defined,  and  the 
guidelines  that  exist  are  oriented  towards  the  justifica¬ 
tion  of  equipment  acquisition.  Therefore,  individual 
projects  do  not  have  an  adequate  management  approach  to 
follow. 

Proposals  submitted  to  MISD  in  accordance  with  AR  18-2 
are  evaluated  only  through  accompanying  cost-benefit  esti¬ 
mates.  There  is  no  meaningful  basis  for  these  judgments, 
and  there  is  no  verification  or  formal  reporting  of  the  cost- 
schedule-performance  status  of  the  projects.  In  addition, 
there  is  no  methodology  for  comparing  actual  progress  and 
costs  with  planning  estimates  or  for  detecting  overruns  or 
other  problems  before  they  are  out  of  control.  Furthermore, 
no  mechanism  exists  to  control  the  changes  that  inevitably 
occur  during  lengthy  development  efforts. 

A  third  problem  is  that  existing  Army  directives  do 
not  provide  a  comprehensive,  consistent  structure  for  man¬ 
agement  information  system  (MIS)  policies,  guidelines,  pro¬ 
cedures,  and  methodology  conventions.  Existing  directives 
do  not  provide  a  uniform  set  of: 

.  policies  stating  goals  and  ground  rules; 

.  procedures  designed  to  achieve  these  goals 
and  implementing  policies;  and 

.  standards,  techniques,  and  conventions. 

Versions  of  such  a  uniform  set  do  exist  among  several 
Army  organizations  ve.g..  Combat  Developments  Command 
and  Army  Materiel  Command).  However,  many  of  the  direc¬ 
tives  follow  AR  18-2  by  emphasizing  automatic  dita 
processing  equipment  and  do  not  address  such  areas  as 
Guidance  and  Reporting  System  development.  The  directives 
do  not  fully  cover  or  integrate  the  development  of  system 
performance  specifications,  computer  programs,  equipment, 
personnel,  and  other  elements  of  the  various  information 
system  types. 

decause  Army  MIS  projects  do  not  have  standard 
guidelines  or  procedures  for  organizing  and  managing 
system  development,  each  project  must  develop  its  own. 
often,  too  little  #?r‘  \s  spent  on  proiect  management. 
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Since  Army  management  information  systems  have  become 
increasingly  complex,  the  requirement  for  a  uniform  set  of 
directives  is  critically  important. 


The  final  problem  faced  by  MISD  is  that  there  are 
not  enough  qualified  personnel  at  HQDA  and  major  commands 
to  centrally  support  the  Army's  management  information 
systems.  This  problem  area  is  widely  recognized  within 
the  Army  and  was  brought  into  sharp  focus  by  the  SOMISS 
effort.  The  SOMISS  effort  also  addressed  the  problems 
caused  by  the  former  organization  of  responsibilities, 
functions,  and  personnel  resources  within  the  Army.  The 
SOMISS  recommendations  now  being  implemented  will  lead  to 
an  improved  institutional  framework  for  developing  and 
managing  MISs.  The  changes  made  will  improve  the  environ¬ 
ment  for  system  management  and  coincide  with  the  recommenda¬ 
tions  of  this  report. 

Recommendations 


Specific  recommendations  to  alleviate  the  problems 
discussed  are  presented  below  in  terms  of  three  time- 
phased  capability  objectives:  immediate,  near-term,  and 
long-term. 

Recommendations  for  Immediate  Action 


As  the  first  step  toward  improving  Army  management  of 
its  management  information  systems.  Peat,  Marwick,  Livingston 
&  Co.  recommends  that  AR  18-xx  be  published.  A  draft  of 
this  AR  is  included  as  Appendix  D.  The  recommended  action 
is  intended  to  remedy  a  number  of  the  deficiencies  in  the 
current  structure  in  the  areas  of  approval,  development,  and 
operation  of  management  information  systems.  It  is  also 
intended  to  contribute  to  a  favorable  environment  for 
further  development  of  the  management  capabilities  of  the 
Office  of  the  Assistant  Vice  Chief  of  Staff.  The  uroposed 
regulation  would  supersede  the  major  part  of  Sections  1, 

2,  and  3  of  AR  18-2,  27  September  1967.  The  remainder  of 
AR  18-2  should  then  be  republished  separately  to  provide 
procedures  for  automatic  data  processing  equipment  acquisition 
and  management.  The  recommended  regulation  includes  the 
following  features: 

.  introduction  of  the  Guidance  and  Reporting 
System,  standard  application,  -?nd  other  con¬ 
cepts  essential  to  the  MIS  management  process: 
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establishment  of  an  approval  and  monitoring 
process,  which  extends  throughput  the  life 
cycle  of  a  management  information  system;  and 

.  delegation  of  a  major  pa_t  of  the  approval 
and  monitoring  process  to  HQDA  staff  agencies 
and  to  major  command  headquarters  agencies. 

Recommendations  for  Near-Term  Capabilities 

Promulgation  of  AR  18-xx,  in  concert  with  the  imple¬ 
mentation  of  SOMISS  recommendations,  will  provide  the 
basis  for  an  improved  MISD  management  capability.  The  next 
step  in  improving  Army  management  of  its  management  informa¬ 
tion  systems  should  extend  and  implement  the  design  concepts 
applied  during  this  study.  The  threefold  objectives  of  the 
implementing  taskwork  would  be: 

.  to  enhance  and  extend  life-cycle  management 
procedures ; 

.  to  develop  a  comprehensive  resource  monitoring 
capability*  and 

.  to  develop  a  comprehensive  systems  management 
guideline. 

Section  VIII  discusses  these  objectiv  s  in  greater  detail. 

Recommendations  for  Long-Term  Capabilities 

The  following  sections  of  this  report  describe  the 
study  results  and  the  management  concepts  and  capabilities 
that  are  MISD's  long-term  objectives.  To  avoid  becoming 
involved  in  a  confusing  sequence  of  tenses.  Sections  II 
through  VII  are  written  exclusively  in  the  present  tense. 
Section  descriptions  are  give:*  K<»low. 

.  Section  II  discusses  the  Army  Management  Information 
System  structure  and  defines  this  structure  in  terms 
of  information  flows  and  information  processing 
systems . 

.  Section  III  details  the  life-cycle  process  of  a 
management  information  system.  The  section 
includes  a  flow  chart  of  system  life-cycle 
activities  and  descriptions  of  each  task  involved. 
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.  Section  IV  describes  the  objectives  of  and 
the  approach  to  monitoring  resource  plans 
and  expenditures. 

.  Section  V  provides  several  related  project 
management  concepts  which  PML  believes  the  Army 
should  apply  to  the  development  of  information 
systems.  These  concepts  involve  the  develop¬ 
ment  environment,  project  reporting,  configuration 
management,  and  system  testing. 

.  Section  Vl  contains  descriptions  of  MISD  activities 
as  they  would  be  performed  in  carrying  out  the 
organization's  day-to-day  management  of  information 
systems.  These  activities  are  supplemented  by 
procedural  checklists,  which  are  given  in  the 
report's  appendices. 

.  Section  VII  discusses  the  criteria  and  method¬ 
ology  needed  to  support  MISD  decision-making. 

The  section  covers  the  determination  of  criteria 
and  their  application  to  MISD  operations. 
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II.  MANAGEMENT  INFORMATION  SYSTEM  STRUCTURE 


Army  Management  Information  System 

When  working  with  the  aggregate  of  management  informa¬ 
tion  systems  within  the  Army,  it  is  useful  to  speak  of  them 
as  the  Army  Management  Information  System  (AMIS) .  This 
term  does  not  imply  the  existence  of  a  monolithic  Army-wide 
information  system.  It  is  simply  a  conceptual  framework 
within  which  individual  management  information  systems 
exist.  Such  a  classification  scheme  is  useful  in  obtaining 
management  control  and  direction  over  component  information 
systems  by  identifying  those  elements  and  resources  that 
are  common  to  each  system. 

The  Army  Management  Information  System  can  be  viewed 
in  two  ways.  One  view  is  functionally  oriented  and  focuses 
on  the  flow  of  information  from  its  basic  source  to  the 
user.  The  information  often  passes  through  several  organi¬ 
zational  levels  en  route.  This  functionally  oriented  view 
encompasses  guidance  and  the  reporting  of  feedback  which  are 
typical  of  the  communication  process.  The  second  view  of 
AMIS  is  oriented  toward  the  set  of  information  processing 
systems  serving  the  needs  of  a  particular  organization  or 
group  of  organizations  within  the  Army.  The  functional 
information  flows  are  referred  to  as  Guidance  and  Reporting 
Systems  (G&RSs)  by  the  Army,  while  the  information  process¬ 
ing  systems  are  referred  to  as  Operating  Information  Systems 
(OlSs)  . 

Figure  II. 1  shows  the  relationship  between  these  two 
systems.  As  illustrated,  a  Guidance  and  Reporting  System 
may  oe  supported  by  one  or  more  Operatirg  Information  Systems. 
Similarly,  an  Operating  Information  System  may  process 
information  for  one  or  more  Guidance  and  Reporting  Systems. 
Thus,  the  G&RS  requirements  of  a  given  Army  organizational 
element  may  be  fulfilled  by  one  or  more  Operating  Informa¬ 
tion  Systems.  In  its  simple  form,  an  OIS  consists  of  one 
computer  application,  located  at  one  data  processing  (DPI), 
supporting  one  G&RS. 

Guidance  and  Reporting  Systems  (G&RSs) 

The  Guidance  and  Reporting  System  concept  provides 
a  way  of  depicting  the  complex  information  flows  within  the 
Army.  A  G&RS  describes  a  cohesive  flow  of  information  from 
the  soui  t  -»  of  data  inputs  to  user  products  and  services. 
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The  requirement  for  this  information  flow  is  usually 
generated  from  the  "top  down,"  in  the  sense  that  new  or 
modified  reporting  requirements  are  stated  at  upper 
levels  (e.g.,  Headquarters,  Department  of  the  Army  (HQDA) 
level,  major  command  level)  and  levied  upon  lower  levels. 

A  G&RS  could  be  initiated  with  the  Chief  of  Staff 
asking  for  Army  personnel  strength  on  a  weekly  basis, 
summarized  by  command/organization,  grade,  etc.  To  satisfy 
this  request,  the  information  must  be  collected  at  the 
lowest  organizational  level,  summarized  at  each  level  up 
to  major  command  or  HQDA/agency,  and  then  transmitted  to 
the  Chief  of  Staff  in  a  report.  This  concept  emphasizes  the 
"top-down"  coordination  that  complex  systems  require. 

Similar  information  requirements  exist  in  all  functional 
areas  and  vary  from  this  simple  illustration  of  collation 
and  summarization  to  complex  requirements  that  dictate 
sophisticated  processing  at  intermediate  levels. 

Individually  and  collectively,  the  Guidance  and 
Reporting  Systems  of  the  Army  place  various  demands  for 
information  processing  on  organizational  elements  within 
the  Army.  These  demands  lead  to  the  second  view  of  AMIS: 
the  Operating  Information  System  Concept. 

Operating  Information  Systems 

Operating  Information  Systems  are  the  actual  information 
processing  activities  at  a  given  organizational  level  of 
the  Army.  Typically,  an  01 S  is  a  set  of  computer  programs 
and  procedures  that  satisfies  the  requirements  of  one  or  more 
Guidance  and  Reporting  Systems.  An  01S  may  range  from  a 
simple  computer  program  at  one  DPI  that  sorts  data  and 
prints  reports,  to  a  sophisticated  system  like  COCOAS, 
which  supports  G&RS  in  three  major  functional  areas  and  will 
be  operated  at  all  Class  II  installations  in  USCONARC. 

The  OIS  concept  is  important  because  Operating 
Information  Systems  are  the  units  that  are  designed,  im¬ 
plemented,  and  operated  within  AMIS  to  satisfy  G&RS 
requirements , 
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III.  LIFE-CYCLE  MANAGEMENT 


A  fundamental  concept  in  Peat,  Marwick,  Livingston  & 
Co.'s  approach  to  AMIS  management  is  that  all  information 
systems  should  progress  through  a  sequence  of  interrelated, 
but  formally  discrete  tasks.  This  process  is  termed  the 
system  life  cycle.  The  life  cycle  may  be  divided  into  three 
major  segments:  requirement  definition,  system  development, 
and  operation.  life-cycle  management  is  the  management  of 
information  systems  through  all  three  segments. 

The  purpose  of  life-cycle  management  is  to  assure 
that  developed  systems  support  the  Army  mission  and  that 
resources  consumed  in  developing  the  systems  are  reasonable. 
The  life-cycle  management  approach  will  give  the  Army 
increased  confidence  in  management  information  systems  by: 

.  establishing  an  improved  means  of  specifying 
information  requirements  in  order  to  better 
support  management  decisions  throughout  the 
life  of  the  system; 

.  providing  an  apparatus  for  integrating  and 

controlling  the  progression  of  events  comprising 
the  life  cycle;  and 

.  providing  for  an  orderly  incorporation  of 
system  changes,  which  are  an  essential 
part  of  all  information  processing  systems. 

Figure  III.l  provides  an  overview  of  the  major  segments 
and  tasks  in  the  system  life  cycle. 


Segment  Descriptions 

The  major  segments  of  the  system  life  cycle  are  described 
in  the  following  paragraphs. 

Requirement  Definition  Segment 

The  requirement  definition  segment  supports  two 
different  planning  efforts  within  the  Army.  The  first  is 
the  continuous  Army-wide  planning  process  that  is  part  of 
the  Army's  Planning-Proaramming-Budgeting  System. 

This  effort  provides  the  Management  Information  Systems 
Directorate  (MISDi  with  the  program  and  resource  informa¬ 
tion  needed  to  guide  and  monitor  AMIS  development.  The 
second  type  of  planning  supported  by  the  requirement 
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definition  segment  is  that  associated  with  individual 
G&RSs  or  OISs.  This  planning,  which  is  discussed  in  detail 
later  in  the  report,  is  the  Key  to  better  control  of  system 
development  because  it  establishes  a  progress  measurement 
guide . 

During  requirement  definition,  information  requirements 
are  defined  and  new  or  modified  Guidance  and  Reporting 
Systems  are  proposed.  Priorities  are  then  established 
for  these  proposals  and  resources  are  allocated.  The  end 
product  of  this  segment  is  the  definition  of  performance, 
cost,  and  schedule  for  each  new  G&RS  or  modification. 

System  Development  Segment 

In  the  system  development  segment,  the  Guidance  and 
Reporting  Systems  previously  defined  are  transformed  into 
Operating  Information  Systems,  which  actually  provide  the 
required  information.  The  development  segment  includes 
preparation  of  OIS  specifications,  the  design,  coding, 
and  testing  of  computer  programs,  hardware  selection  and 
procurement,  and  many  other  tasks  necessary  to  produce  an 
Operating  Information  System.  The  end  product  of  this 
segment  is  one  or  more  Operating  Information  Systems  that 
effectively  satisfy  the  Guidance  and  Reporting  System 
requirements  at  a  reasonable  cost. 

Operation  Segment 

When  the  OIS  becomes  operational,  a  continual  evalua¬ 
tion  process  begins.  This  evaluation  measures  the  infor¬ 
mation  provided  by  the  system  against  individual  user  re¬ 
quirements.  The  result  may  involve  refinement  of  the  OIS, 
changes  to  the  G&RS,  or  a  major  reworking  of  the  AMIS 
structure  to  meet  new  requirements.  Throughout  this 
segment,  changes  to  the  system  must  be  controlled,  and 
adequate  documentation  must  be  maintained  to  support  the 
continual  changes  and  modifications  inherent  in  such 
systems . 


Task  Descriptions 

The  tasks  described  below  represent  the  major  steps 
in  developing  information  systems  for  the  Army.  The  process 
outlined  is  not  the  only  way  to  develop  a  system,  but  it 
is  a  proven  approach  to  such  an  effort.  The  tasks  identi¬ 
fied  should  not  be  interpreted  as  the  only  important  tasks 
in  the  system  life  cycle,  but  rather  as  points  of  departure 


II 1 .2 


-  /I  •f/.Vxnfii  /»•  t  ,4  t  r- 


for  developing  the  task  descriptions  for  individual  system 
projects.  These  tasks  provide  valuable  bases  for  planning, 
controlling,  and  evaluating  the  system  development  process. 
The  documents  used  to  record  the  various  tasks  are  also 
described,  although  emphasis  is  placed  on  the  content  and 
accomplishment  of  the  tasks  rather  than  on  the  documents. 

The  life  cycle  is  illustrated  in  a  flow  chart 
(Figure  III. 2)  at  the  end  of  this  section.  The  numbered 
task  descriptions  correspond  to  the  numbered  blocks  on 
the  flow  chart.  The  tasks  and  documents  are  the  same  as 
those  illustrated  in  Figure  III.l. 

Requirement  Definition  Segment 

1  -  Identify  Information  Requirements.  This  is  the 
initial  recognition  of  an  information  requirement.  The 
requirement  may  be  for  new  information  or  for  changes  to 
information  currently  provided.  It  usually  is  identified 
in  the  upper  echelons  of  the  Army  and  requests  information 
from  subordinate  organizations.  Conversely,  it  is  possible 
to  have  a  request  for  information  initiated  at  a  lower  level. 
The  ceneration  of  an  independent  proposal  or  request  for 
information  requirements  is  also  possible. 

The  initial  information  requirement  is  documented  in  a 
Reporting  System  Requirement  (RSR) ,  whose  primary  purpose 
is  to  describe  the  basic  functions  to  be  performed  and  the 
types  of  information  needed  to  satisfy  these  functional 
requirements.  A  secondary  purpose  of  the  RSP  is  to  allow 
a  central  agency  in  the  Army  to  consolidate  and  review  the 
various  information  requirements  and  to  insure  clarity  and 
coordination  between  the  information  user  and  the  system 
developer . 

2  -  Review  and  Evaluate  RSRs.  The  responsible  staff 
agency  reviews  and  evaluates  all  RSRs  related  to  a  particular 
functional  area.  In  addition,  MISD  receives  copies  of  all 
RSRs.  The  purpose  of  this  review  and  evaluation  is  to  com¬ 
pare  specific  information  requirements  with  Army  goals  and 
missions  and  to  eliminate  duplicate  requirements.  The 
staff  agency  submits  its  evaluation  and  recommendation  for 

or  against  satisfying  the  requirement  to  MISD.  MISD  then 
prepares  a  Reporting  System  Directive  (RSD)  and  sends  it 
to  the  proponent  of  the  RSR.  The  RSD  directs  the  proponent 
to  prepare  a  Guidance  and  Reporting  System  Specification 
(RSS)  to  specifically  define  the  reporting  requirements 
that  must  be  satisfied.  The  purpose  of  the  Reporting 
System  Directive  is  to  provide  guidance  to  the  proponent 
in  defining  the  reporting  requirements. 
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3  -  Design  Guidance  and  Reporting  System  Specification 
(RSS) ~  The  originator  of  the  requirement  must  prepare  a 
detai led  specification  of  the  reporting  system  requirements 
in  conjunction  with  the  responsible  staff  agency.  This 
specification  (i.e.#  the  RSS)  is  developed  following  the 
guidance  given  in  the  RSD  and  forms  the  basis  for  future 
development  of  data  processing  activities  required  to  support 
the  reporting  system.  The  specification  defines  the  flow 

of  all  information  from  the  source,  through  data  processing, 
to  the  user. 

The  Guidance  and  Reporting  System  Specification  (RSS) 
is  a  formal  documentation  of  the  information  flow  within 
AMIS.  The  analysis  required  to  produce  the  RSS  must  include 
studies  of  similar  information  requirements  at  various 
levels  within  the  Army  and  within  major  commands. 

4  -  Review  and  Evaluate  RSS.  The  RSS  is  reviewed  and 
evaluated  by  the  responsible  staff  agency,  MISD,  and  other 
HQDA  elements.  This  review  is  to  ensure  that  a  comprehensive 
specification  of  reporting  system  requirements  has  been  pre¬ 
pared  and  that  it  presents  sufficient  information  to  support 
the  decision-making  process  that  follows. 

5  -  Identify  Operating  Information  System  Requirements. 
This  task  includes  defining  the  basic  requirement  for  an 
OIS ,  descriptions  of  the  functions  to  be  performed,  identi¬ 
fication  of  the  reporting  systems  supported,  identification  of 
DPIs  irvolved,  and  estimates  of  resource  requirements.  It 

is  directed  at  an  initial  description  of  an  individual  OIS 
and  is  documented  in  an  Operating  Information  System  Require¬ 
ment  (OISR) ,  which  is  used  to  justify  the  establishment  or 
an  Operating  Information  System  Project  Office. 

6  -  Review  and  Evaluate  OISR.  The  responsible  staff 
agencies  review  and  evaluate  all  OISRs  that  support  areas 
related  to  their  functions.  In  addition,  MISD  receives 
information  copies  of  all  OISRs.  The  purpose  of  this  review 
and  evaluation  is  to  compare  specific  OIS  requirements 

with  * rry  goals  and  missions  and  to  eliminate  duplicate 
roqui remen t  s . 

The  staff  agencies  submit  evaluations  of  and  recommen¬ 
dations  on  the  proposed  OIS  to  MISD.  MISD  than  prepares 

an  Ppcr.ttin<i  Information  Oyster  Cirrftuv  (OISD)  and  sends 
;t  to  the  originator  of  the  ^ISR.  The  uISD  directs  the  pro¬ 
ponent  to  oreparr  an  operatir.a  Inforratior  Systor  Development 
Plan  and  op*>rattnq  Information  System  Specification  tc  spe¬ 
cifically  define  the  requirements  that  rust  Ic  satisfied.  It 
also  aids  the  orononent  in  prooarmc  the  documentation. 
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7  -  Make  Decision  To  Implement  OIS.  This  is  the  first 
major  decision  point  in  the  life-cycle  process.  It  requires 
an  answer  on  the  question  of  committing  Army  resources  to 
design  the  Operating  Information  System (s)  necessary  to 
support  a  particular  GSRS.  Before  such  a  decision  can  be 
made,  the  Reporting  System  Specification (s)  must  be  assessed 
in  terms  of  the  available  resources,  objectives,  and 
missions  of  the  Army  or  the  command  involved.  Various 
alternative  decisions  are  possible,  ranging  from  approval, 
to  rewriting,  to  disapproval  of  an  individual  RSS.  If  the 
Army  decides  to  proceed  with  development,  a  monitoring 
agency  to  coordinate  OIS  development  is  designated. 

The  decision  to  implement  an  OIS  generally  arises  from 
one  of  two  major  situations.  The  first  situation  that  can 
lead  to  such  a  decision  is  the  specification  of  one  or  more 
new  or  revised  GtRSs  that  must  be  implemented,  while  this  is 
the  most  frequent  cause  for  generating  OISs,  the  recognition 
that  a  new  OIS  is  required  to  process  existing  3&RS  more 
efficiently  or  economically  can  also  result  in  a  decision 
to  implement  an  OIS. 

8  -  Analyze  System.  The  system  analysis  task  produces 
the  performance,  design,  and  test  requirements  for  a  specific 
OIS.  This  analysis  involves  determining  the  performance 
requirements  in  terms  of  the  various  resources  of  the  system, 
(e.g.,  the  equipment,  computer  programs,  personnel,  etc.). 

The  product  of  this  analysis  is  a  system  specification  for 
the  OIS,  the  Operating  Information  System  Specification 
(OISS) .  The  OISS  identifies  all  performance/design  require¬ 
ments  to  be  satisfied  by  the  operating  system.  It  describes 
each  function  that  must  be  performed  in  terms  of  inputs, 
outputs,  and  processing  requirements.  The  specification 
identifies  the  equipment,  facilities,  personnel,  procedures, 
and  other  elements  required  by  the  system.  In  addition,  it 
defines  the  baseline  against  which  the  OIS  is  designed  and 
tested. 

9  -  Develop  System  Project  Plan.  A  project  plan  to 
guide  OIS  development  is  prepared  in  parallel  with  the  system 
analysis.  This  includes  preparation  of  cost  and  schedule 
estimates  for  the  system  deve lopment  phcse.  The  plan  con¬ 
tains  a  management  structure  for  the  project  and  descriptions 
of  the  specific  tasks  to  be  accomplished.  Organisations 
responsible  for  performing  these  tasks  must  be  identified. 

The  Operating  Information  System  Development  Plan  (01SDP)  and 
the  Operating  Information  System  Specification  (OISS)  form 
the  basis  for  the  second  major  decision  in  the  life-cycle 
process. 
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10  -  Make  Decision  to  Develop  the  Operating  Infqraation 
System!  This  is  the  last  task  in  the  requirement  definition 
segment.  It  involves  the  acceptance  or  rejection  of  the 
OISDP  and  OISS  by  the  MISD  and  HQDA  staff  and  an  agreement 
that  the  ODerating  Information  System  specified  will  satisfy 
the  appropriate  Guidance  and  Reporting  Systems.  The  decision 
to  proceed  signifies  the  commitment  of  resources  outlined  in 
the  plan  to  develop  the  OIS  that  is  described  in  the  speci¬ 
fication. 

System  Development  Segment 

11  -  Define  Application  Requirements.  The  individual 
application  specifications  are  developed  from  the  system 
specification.  The  specification  for  an  application  contains 
all  the  performance,  design,  and  test  requirements  for  an 
individual  application.  The  specification  also  identifies 
and  defines  all  the  interfaces  between  the  application  and 
other  applications  and  equipment.  Once  approved,  the  design 
specification  will  control  the  development  of  that  appli¬ 
cation.  Thus,  the  application  is  designed  and  qualified 

in  accordance  with  its  individual  design  specification. 

12  -  Conduct  Preliminary  Design  Re* iew.  The  Preliminary 
Design  Review  (PDP)  is  held  to  evaluate  the  design  approach 
for  the  applications  in  light  of  the  overall  system  require¬ 
ments.  Its  prime  objective  is  to  ensure  design  integrity. 

A  review  of  the  interfaces  affecting  the  application  programs 
is  an  important  element  of  a  PDR.  Emphasis  is  placed  on 
verifying  detailed  interfaces  with  equipment  and  with  other 
application  programs.  The  programming  features  of  the 
computer  (e.g.,  interrupts,  multiprocessing,  time-sharing, 
etc.)  must  be  known,  and  all  external  data  formats  and 
timing  constraints  must  be  identified.  The  computer 
program  storage  requirements  and  data  base  design  are  re¬ 
viewed  for  technical  adequacy  at  this  time.  The  structure 
of  the  Ois  is  also  reviewed. 

13  -  Prepare  Detailed  Application  Specification.  This 
effort  involves  the  translation  of  the  application  design 
information  into  detailed  flow  charts,  logic,  etc.,  suitable 
for  coding.  The  documentation  of  this  effort  forms  the 
first  element  of  the  detailed  specification  for  the  appli¬ 
cation  or  computer  program. 

14  -  Conduct  Detailed  Design  Review.  The  Detailed  Design 
Review  (DDR)  is  a  formal,  technical  review  of  the  design 

of  the  application  programs  at  the  detailed  flow  chart  level. 

It  is  held  to  establish  the  integrity  of  the  program  design  pri¬ 
or  to  coding  and  testing.  In  the  case  of  a  complex  aoolication 
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program,  a  OCR  is  held  for  each  component  as  its  design 
proceeds  to  the  detailed  flow  chart  level.  At  the  DDR, 
the  completed  sections  of  the  application's  detailed 
technical  description  are  reviewed  along  with  supporting 
analytical  data,  test  data,  etc.  The  compatibility  of 
the  program  design  with  the  requirements  of  the  applies* 
tion  specification  is  established  at  the  DDR.  Design 
integrity  is  established  by  reviewing  analytical  and  test 
data  in  the  form  of  logic  design,  algorithms,  storage 
allocations,  and  associated  methodology. 

In  general,  the  primary  product  of  the  DDR  is  the 
establishment  of  system  design  and  development,  which  are 
the  technical  bases  for  the  continuation  of  the  program  de¬ 
velopment  cycle.  Immediately  following  the  Detailed  Design 
Review,  the  individual  components  are  coded,  and  the  process 
of  checkout  and  testing  the  components  begins. 

15  •  Code  Programs.  This  effort  involves  converting 
the  detailed  design  into  usable  computer  programs.  The 
output  is  a  set  of  instructions  (e.g.,  cards,  magnetic 
tape,  etc.)  documented  by  annotated  program  listings. 

Preparing  the  initial  tests  required  to  assure  an  operable 
computer  program  is  also  part  of  this  effort.  This  task 
provides  the  final  element  of  the  detailed  application 
specifications  that  document  the  activities  of  blocks  12, 

13,  14,  and  15. 

16  *  Develop  System  Test  Approach.  The  purpose  of 
test  planning  is  to  develop  a  comprehensive  approach  to 
qualification  tests,  system  tests,  and  pilot  testing 

of  the  system.  This  approach  must  be  complete  with  schedules, 
test  methods,  and  criteria;  identification  of  simulated 
versus  l*ve  inputs;  and  support  requirements  for  test  equip¬ 
ment,  facilties,  special  test  computer  programs,  and 
personnel.  The  resulting  system  test  plan  forms  the  oasis 
for  test  procedures  prepared  later  to  describe  individual 
tests  in  detailed  terms,  specifying  objectives,  inputs, 
events,  recording/data  reduction  requirements,  and  expected 
results.  The  system  test  plan  is  essential  to  the  develop¬ 
ment  effort  since  it  identifies  the  tasks  related  to  testing 
and  defines  responsibilities  for  accomplishing  those  tasks. 

17  -  Design  Tests.  The  detailed  design  of  system  tests 
to  complement  the  system  test  plan  is  accomplished  in 
parallel  with  the  detailed  application  design.  The  test 
program  developed  generally  is  a  series  of  tests  that  vary 
in  scope  from  tests  of  individual  components  to  total  system 
tests.  For  each  series  of  tests,  detailed  testing  procedures 
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are  developed  that  identify  the  test  objectives,  resources, 
expected  results,  specific  actions  to  be  taken,  and  so 
forth.  These  test  procedures  are  used  as  guides  in  conducting 
the  individual  tests  of  the  system. 

18  -  Test  Programs.  When  individual  components  of  the 
program  are  coded,  they  are  tested  in  accordance  with 

pre  -Dusly  developed  procedures.  The  testing  is  conducted 
in  a  modular  fashio.  ,  starting  with  small  components  and 
adding  modules  until  the  whole  system  has  been  tested. 
Individual  system  elements  are  tested  to  ensure  that  the 
system  meets  its  design  specification  and  is  ready  for 
system  level  tests. 

19  -  Conduct  System/Pilot  Tests.  When  all  elements 
of  the  system  are  qualified,  system  level  tests  begin. 

These  tests  are  conducted  to  ensure  that  the  elements  work 
together  to  satisfy  the  requirements  in  the  system  specifi¬ 
cation.  The  system  tests  duplicate,  as  far  as  possible, 
real  system  operating  conditions.  During  the  pilot  test, 
real  data  is  processed  by  the  system  to  show  that  the  system 
satisfies  the  specification  under  operating  conditions. 

20  -  Develop  User  Documentation.  Various  user-oriented 
documents  are  prepared  in  conjunction  with  the  detailed  design 
and  development  of  computer  programs.  These  documents 
extract  information  concerning  the  operation  and  use  of 

the  system  from  the  technics*  documentation  previously  de¬ 
veloped.  The  documentation  is  structured  and  written 
expressly  for  the  individual  types  or  groups  of  people 
using  or  operating  the  system.  Drafts  of  these  documents 
are  available  for  the  system  and  pilot  tests  so  that  their 
effectiveness  can  be  evaluated. 

21  -  Audit  Documents.  When  the  design  and  testing  of 
the  computer  programs  is  essentially  completed,  the  detail 
specification  is  made  available  for  review.  The  detail 
specifications  provide  a  complete  and  detailed  technical 
description  of  the  computer  programs  "as  built,"  and 
function  as  the  primary  document  for  use  by  programmers 

in  correcting  errors  m  and  designing  changes  to  the 
c^mnuter  programs.  The  technical  accuracy  and  complete¬ 
ness  of  the  specifications  are  determined  prior  to 
acceptance  of  the  document  by  the  Army.  The  document 
audit  is  the  vehicle  for  the  required  review  of  the  detail 
specification  and  is  an  audit  of  the  specification  and  the 
computer  programs  as  delivered.  The  primary  product  of 
the  review  is  formal  acceptance  by  the  Artsy  of  the 
specification  as  an  audited  and  approved  document. 
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Acceptance  of  the  computer  programs  for  pilot  testing 
is  based  on  the  successful  completion  of  the  system  test 
program  and  the  audit,  but  it  does  not  relieve  the  developer 
of  meeting  the  requirements  of  the  system  specification. 
Subsequent  to  the  review,  the  configuration  of  the  computer 
program  is  essentially  controlled  at  the  machine  instruction 
level  so  that  the  exact  configuration  is  available  for  pilot 
testing. 

22  -  Install  System.  After  a  successful  pilot  test, 
the  system  is  installed  at  operational  sites.  This  effort 
includes  site  and  facility  preparation,  equipment  installa¬ 
tion,  computer  program  installation,  and  implementation 
testing.  These  tests  are  designed  to  ensure  that  subsequent 
sites  are  identical  to  the  pilot  installation.  This  repre¬ 
sents  the  end  point  of  the  system  development  segment. 

Operation  Segment 

23  -  Begin  Operations.  The  system  is  now  operational 
and  performing  its  intended  mission. 

24  -  Remove  or  Replace  System.  Eventually  the  system 
is  deleted  from  the  Army  inventory.  To  accomplish 

this,  a  number  of  tasks  are  performed.  Disposition  of 
equipment  and  relocation  of  personnel  require  careful 
consideration. 

Responsibilities 

Individual  responsibilities  for  life-cycle  management 
are  described  in  the  following  paragraphs. 

Management  Information  Systems  Directorate  (MISD) 

The  Management  Information  Systems  Directorate  is 
responsible  for  overall  guidance  and  coordination  of 
systems  throughout  the  system  life  cycle.  MISD's  role  is 
to  ensure  that  the  total  Army  Management  Information 
System  (AMIS)  satisfies  Army  mission  requirements.  Specific 
MISD  responsibilities  are: 

.  to  review  and  approve  the  development  of 
system  specifications  and  assign  responsi¬ 
bility  for  their  development  to  an  appropriate 
HQDA  staff  agency; 

.  to  review  and  approve  OIS  requirements  and 
development  proposals  and  assign  a  monitoring 
agency  (MA)  within  the  HQDA  staff;  and 
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.  to  maintain  continuing  surveillance  over  all 
information  system  projects  by  means  of 
periodic  progress  reporting  and  liaison  with  the 
assigned  MA. 

HQDA  Staff  Agencies 

Each  HQDA  staff  agency  is  responsible  for  the  develop 
ment  of  all  assigned  Guidance  and  Reporting  Systems  and 
for  monitoring  all  the  functional  areas  (e.g.,  personnel, 
finance,  logistics,  etc.)  of  each  system.  Specifically, 
each  HQDA  staff  agency: 

.  identifies  and  defines  the  information  needs  of 
management  in  HQDA  in  the  appropriate  functional 
area  and  defines  G&RSs  and  OISs  to  meet  those 
needs ; 

.  prepares  detailed  specifications  for  G&RSs 
when  such  systems  supply  information  to  HQDA; 

.  monitors  the  development  and  operation  of  the 
functional  components  of  Operating  Information 
Systems  to  ensure  that  they  fully  satisfy  the 
specifications  of  the  Guidance  and  Reporting 
Systems  they  support;  and 

.  acts  as  an  MA  (when  so  directed  by  MISD)  to 
oversee  all  development  activity  and  ensure 
that  the  system  design  meets  management  require¬ 
ments  within  established  time  and  cost  con¬ 
straints  . 

Responsibility  for  OIS  Development 

During  the  life  cycle  of  an  Operating  Information 
System  or  system  development  project,  several  management 
and  technical  responsibilities  are  undertaken.  Among 
those  who  assume  these  responsibilities  are: 

.  monitoring  agencies  (MAs)  -  HQDA  staff  agencies 
appointed  by  MISD  to  take  responsibility  for 
approving  and  monitoring  the  development  and 
operations  of  Operating  Information  Systems. 

For  OISs  that  are  confined  to  single  functional 
areas,  a  HQDA  staff  agency  having  expertise 
in  that  functional  area  is  designated  by  MISD 
as  MA.  If  OISs  and  OIS  development  projects 
support  particular  G&RSs,  the  MA  is  the  HQDA 
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staff  agency  or  other  HQDA  agency  responsible 
for  design  and  development  of  the  system.  If 
OISs  and  OIS  development  projects  extend  across 
two  or  more  functional  areas,  MISD  assumes  the 
role  of  MA; 

responsible  development  agencies  (RDAs)  -  organiza¬ 
tions  responsible  for  design  and  development  of  OISs. 
They  are  specifically  responsible  for  the  design 
and  development  of  OIS  programs  and  procedures. 

RDAs  are  usually  Army  major  commands  designated  by 
MISD;  and 

project  managers  (PMs)  -  individuals  designated 
by  appropriate  authority  who  are  responsible  for 
managing  an  improvement  project.  In  the  case  of 
an  OIS  development  project,  the  PM  is  designated  by 
the  RDA. 


requirement  definition  segment 
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figure  in?  — information  system  life-cycle  process 


IV.  RESOURCE  MONITORING 


The  overall  objective  of  resource  monitoring  is  to 
supply  the  Army  with  tools  to  analyze  and  evaluate  resource 
expenditures  for  information  systems.  These  tools  provide 
the  Army  with  the  financial  visibility  necessary  to  support 
decision-making  throughout  the  life  of  the  information  systeaui. 
Specific  objectives  of  the  resource  monitoring  procedures 
are: 

.  to  provide  improved  visibility  of  information 
systems  in  the  Department  of  the  Army  budget; 

.  to  collect  actual  resource  consumption  data  for 
system  development  and  operation; 

.  to  provide  an  improved  basis  for  Army  resource 
allocation  during  system  development  and 
operations;  and 

.  to  provide  the  Army  with  the  means  to  establish 
financial  control  over  the  development  and 
operation  of  these  systems. 

The  monitoring  of  resource  expenditures  has  two 
distinct  functions,  planning  and  control.  The  planning 
function  begins  early  in  the  system  life  cycle  and 
consists  of  developing  comprehensive ,  carefully  considered 
project  plans  in  the  areas  of  cost,  project  scheduling,  and 
system  performance.  These  plans  define  baselines  against 
which  progress  is  measured  and  against  which  the  impact 
of  proposed  changes  on  project  plans  is  assessed.  The  con¬ 
trol  function  consists  of  cc  urino  actual  progress  with 
these  plans  and  taking  appropriate  action,  e.g.,  changes 
to  assure  completion  of  a  project  within  the  constraints 
of  schedule,  cost,  and  performance.  Both  functions  continue 
throughout  the  life  cycle. 

Approach 

In  general,  resource  information  is  given  in  terms  of 
either  estimated  or  actual  resource  expenditures.  The 
collection  of  these  two  types  of  resource  information 
(i.e.,  estimated  and  actual)  during  each  of  the  three 
system  life-cycle  segments  is  discussed  in  detail  below. 
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Requirement  Definition  Segment 


A  proposed  reporting  system  is  defined  early  in  the 
requirement  definition  segment.  Estimates  of  the  resources 
required  to  implement  such  a  system  are  also  given.  This 
information  includes  gross  estimates  for  the  cost  of 
renting  or  purchasing  automatic  data  processing  equipment 
(A3PE) ,  of  contractual  support  and  other  exoenses,  and  of 
the  personnel  requirements  in  terms  of  military  and  civilian 
man-years.  The  information  is  compiled  for  the  current 
fiscal  year  and  the  five  following  fiscal  years;  it  is 
prepared  by  the  proponent  of  the  new  reporting  system.  If 
the  system  is  to  be  implemented  at  more  than  one  major 
organizational  level  within  the  Army,  estimates  are 
developed  for  each  organizational  level  involved.  The  in¬ 
formation  is  formally  prepared  as  part  of  a  Reporting  System 
Requirement  (RSR)  or  a  Reporting  System  Specification  (RSS) . 

In  addition,  if  a  major  change  to  the  Army  budget  or  the 
Five-Year  Defense  Plan  (FYDP)  is  required,  a  Program  Ch.ing*- 
Proposal  is  prepared  for  review  and  analysis  by  MISD  and  the 
Army  staff. 

The  next  major  task  is  the  definition  of  the  Operating 
Information  Systems  required  to  implement  one  or  more  re¬ 
porting  systems.  This  definition  is  prepared  by  the  operating 
system  design  agency.  An  essential  part  of  such  a  definition 
is  an  estimate  of  the  resources  required  for  development 
and  operation  of  the  Operating  Information  Systems. 

System  Development  Segment 

The  resource  information  for  the  system  development 
segment  is  of  the  same  form  as  that  for  the  requirement 
definition  segment,  but  the  estimates  are  more  accurate  and 
are  supported  by  in-depth  analysis  and  detailed  resource 
estimates.  The  information  is  again  compiled  for  the 
current  fiscal  year  and  the  five  following  years.  It  is 
also  compiled  by  Army  organizational  level  if  applicable. 

In  addition,  an  OIS  that  supports  more  than  one  reporting 
system  allocates  the  total  development  costs  to  the  re¬ 
porting  systems  involved  to  ariive  at  the  development  cost 
of  an  individual  repotting  system. 

The  collection  of  actual  resource  expenditures  is 
co»ff>licated  by  the  manner  in  which  systems  are  developed. 
System  projects  permit  the  collection  of  resource  expendi¬ 
ture  data  through  the  Army  accounting  system.  Systems 
not  assigned  to  specific  projects  and  developed  through 
DPI  resources  require  separate  reporting  procedures  to 
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gather  resource  expenditure  data.  The  best  way  to  collect 
these  data  appears  to  be  through  an  expansion  of  the  existing 
ADPE  system  (1AW  AR  18-3).  This  results  in  what  is  es¬ 
sentially  a  mar  hour  accounting  system  for  those  engaged 
in  operation  of  information  system  and  in  development 
of  new  information  systems.  If  the  amount  of  the  system 
development  work  conducted  by  individual  DPIs  becomes 
negligible,  this  information  is  no  longer  required. 

Operation  Segment 

Resource  information  for  the  operation  of  the  systems 
includes  identification  of  the  personnel  required  to  operate 
and  support  the  system  and  of  equipment  rental  costs  in¬ 
curred  in  op  rating  the  system.  Any  other  unusual  cost  of 
operations  (e.g.,  for  unique  consumables  purchases)  is  also 
identified. 

The  initial  estimates  for  resources  required  to  operate 
new  oiSs  are  made  during  the  development  phase  by  the  op¬ 
erating  system  design  agencies.  Estimates  for  continuing 
ooerations  are  made  by  individual  DPIs  and  assembled  as 
DPI  operating  budgets.  This  information  is  displayed  on  an 
OIS  basis  and  is  summarized  to  show  the  total  cost  of 
DPI  operations. 

The  cost  of  operating  an  individual  DPI  is  collected 
and  reported  through  the  Army  accounting  system  for  com¬ 
parison  with  the  budgetary  figures.  Collection  of  resources 
on  an  individual  OIS  basis  may  be  through  an  extension  of  the 
existing  Controller  of  the  Army  (COA)  ADPE  reporting  system. 
This  provides  actual  resource  expenditure  information  for 
operating  systems  and  individual  reporting  systems  where 
possible.  To  ensure  accuracy,  the  information  collected 
through  the  ADPE  reporting  system  is  reconciled  with  that 
collected  through  the  accounting  system  at  the  end  of  a 
reporting  period. 
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V.  RELATED  PROJECT  MANAGEMENT  CONCEPTS 


To  achieve  the  management  capabilities  represented 
by  the  life-cycle  concepts  and  resource  monitoring  require¬ 
ments,  a  number  of  related  tools,  which  involve  the  manner 
ir.  which  development  activities  are  organized  and  controlled, 
are  required.  These  tools  are  project  reporting,  configura¬ 
tion  management,  and  system  testing. 


Assumptions 

Before  explaining  the  tools  referred  to  above,  several 
Peat,  Marwick,  Livingston  k  Co.  assumptions  about  system 
developmental  environment  must  be  understood.  These 
assumptions  involve  three  areas: 

.  how  efforts  to  improve  systems  are  organized 
(project  organization); 

.  how  development  resources  are  controlled 
(resource  control) ;  and 

.  how  development  methodology  is  adapted  to 
the  size  and  complexity  of  the  systems  being 
developed  (system  size/scope) . 

PML  feels  these  areas  are  key  elements  to  understanding 
and  improving  M1SD  capabilities. 

Project  Organization 

PML  expects  a  project  management  type  of  organization 
to  be  used  for  the  development  of  Operating  Information 
Systems.  This  type  of  management  implies  that  an  individual 
project  manager  has  specific  responsibilities  and  commen¬ 
surate  authority  for  development  of  individual  systems. 

This  project  manager  is  responsible  for  meeting  stated 
performance  requirements  within  the  schedule  and  cost 
constraints  of  an  individual  CIS.  He  must  make  effective 
use  of  the  resources  at  his  disposal  within  the  confines  oi 
three  parameters:  time,  cost,  and  performance. 

The  project  management  concept  uses  the  team  approach 
to  designing  and  developing  a  system.  Functional  experts 
work  with  the  system  usei  under  the  direction  of  ;ho 
manager.  Detailed  plans  are  developed  for  cost,  ^c^edule, 
and  performance  of  the  project,  and  these  plans  nude 
the  project  office  in  achieving  the  objective,  i.e...  an 
operating  Information  System. 


The  project  organization  may  take  several  forms, 
depending  upon  the  scope  and  nature  of  the  work  and  the 
life-cycle  phase.  The  need  for  clearly  defined  project 
responsibilities  can  be  seen  by  examining  the  following 
possible  organization  structure*  : 

.  an  aggregated  organization,  in  which  all  personnel 
and  other  project  resources  are  under  the  direct 
supervision  of  the  project  manager; 

.  a  mixed  organization,  in  which  some  important  de¬ 
velopmental  functions  (e.g.,  facility  construc¬ 
tion)  are  not  under  the  direct  supervision  of 
the  project  manager,  even  though  he  has  coordina¬ 
tion  responsibilities  for  these  functions.  Remaining 
development  and  staff  functions  do  report  to  the 
project  manager; 

.  a  staff  organization,  in  which  the  project 
manager  directly  exercises  control  of  all 
resources  committed  to  project-unique  functions 
(e.g.,  planning,  task  and  financial  management, 
configuration  and  change  control,  or  site 
activation) ,  but  does  not  control  primary  func¬ 
tional  tasks  usually  performed  by  HQDA  staff 
agencies  or  commands  (e.g.,  engineering,  pro¬ 
curement,  and  facility  construction).  Again, 
administrative  and  coordination  responsibilities 
remain  with  the  project  manager;  and 

.  an  individual  project  consisting  of  only  the 
project  manager  and  required  administrative 
staff  personnel,  in  which  all  project  control 
is  exercised  via  HQDA  staff  agencies  or  commands. 

Resource  Control 


In  the  resource  utilization  area,  it  is  assumed  that 
whether  the  resources  come  from  a  contractor,  a  programming 
pool,  or  an  individual  project  office,  the  personnel  in¬ 
volved  are  responsible  to  the  project  manager  for  the 
accomplishment  of  tasks  related  to  project  development. 

The  project  manager  must  have  control  of  and  responsibility 
for  all  the  resources  expended  on  his  project  to  most 
effectively  perform  his  managerial  duties. 
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At  the  present  time ,  the  Army  Management  Information 
System  is  undergoing  a  transition  from  a  large  number  of 
relatively  small  systems  to  a  smaller  group  of  larger, 
more  sophisticated  systems  (e.g.,  COCOAS).  Informed 
sources  expect  more  sophisticated  systems,  which  satisfy 
wider  functional  areas,  will  be  built  in  the  future, 
and  that  the  smaller  systems  will  eventually  be  deleted 
from  the  inventory.  The  development  methodology  recommended 
for  use  by  MISD  is  primarily  aimed  at  the  larger  systems. 
However,  it  is  adaptable  for  use  on  less  complex  projects. 

The  tools  for  this  development  methodology  are  explained 
in  the  remainder  of  this  section,  and  supplemental  informa¬ 
tion  appears  in  Appendix  B. 

Development  Methodology  Tools 

Project  Reporting 

Project  reporting  is  designed  to  meet  the  basic  in¬ 
formation  requirements  for  management  of  OIS  projects.  The 
data  provided  by  project  reporting  also  support  the  moni¬ 
toring  of  all  development  efforts  by  MISD.  Project  re¬ 
porting  involves  a  hierarchy  of  reports  which  vary  in 
levels  of  detail.  Examples  of  a  report  hierarchy  are 
described  in  Appendix  B.  The  project  reporting  approach 
permits  an  adaptation  of  an  OIS  to  the  demands  of  any 
project . 

Operating  Concept 

The  operating  concept  for  project  management  reporting 
is  portrayed  in  flow  chart  form  in  Figure  V.l.  This  chart 
illustrates  how  data  inputs  are  received,  how  the  informa¬ 
tion  is  processed,  and  now  the  output  reports  are  distributed. 
Individual  responsibility  for  preparation  of  the  project 
management  reports  rests  with  the  project  office.  MISD  is 
responsible  for  the  preparation  and  distribution  of  the 
summary  reports. 

Data  Inputs 

The  initial  data  inputs  are  taken  from  the  documenta- 
cion  used  for  approval  of  the  project,  e.g.,  the  Operating 
Information  System  Development  Plan  (OISDP) .  These  in¬ 
clude  the  work  breakdown  structure  (WBS) ,  the  time-phased 
budget  plan,  the  implementation  schedules,  rid  clearly  de¬ 
fined  responsibilities  for  the  various  project  tasks  at  the 
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government  and  contractor  levels.  The  data  forms  the  cost, 
schedule,  and  performance  baselines  to  which  actual  progress 
is  subsequently  compared. 

Configuration  Management 

Configuration  management  is  a  second  management 
technique  that  aids  in  project  control.  This  technique 
establishes  procedures  for  controlling  the  performance 
requirements  and  the  actual  configurations  of  the  various 
parts  of  a  system  and  their  associated  documentation. 

Contrary  to  a  prevalent  misconception,  configuration 
management  is  not  synonymous  with,  nor  a  substitute  for, 
the  technical  system  engineering/analysis  effort  that  is 
the  heart  of  system  design  and  development.  However,  it 
is  closely  related  to  other  areas  of  systems  management, 
particularly  with  the  processes  of  system  engineering 
and  testing.  Configuration  management  applies  to  items 
of  computer  programs,  equipment,  and  facilities,  which  are 
identified  as  the  major  elements  of  an  Operating  Informa¬ 
tion  System. 

Within  the  scope  of  configuration  management,  distinc¬ 
tion  is  made  between  the  three  major  sub-processes  of  iden¬ 
tification,  control,  and  accounting. 

Configuration  identification  refers  to  the  techni¬ 
cal  definition  of  the  system  and  its  parts.  Primarily,  this 
definition  takes  the  form  of  specifications.  In  general, 
configuration  management  is  based  on  the  concept  of  uniform 
specifications,  which  implies  that  in  each  system  project 
there  should  be  one  general  specification  for  the  system 
as  a  whole  and  one  specification  for  each  major  element. 
General  format  and  content  requirements  of  the  specifica¬ 
tions  are  uniform  for  all  systems.  Detailed  requirements 
for  specification  format  and  contents  are  different  for  the 
major  elements  (e.g.,  equipment,  facilities,  and  computer 
programs) . 

Once  written  and  approved,  each  specification  formally 
defines  a  baseline  for  the  system  or  element.  A  baseline  is 
an  established  and  approved  configuration,  constituting  an 
explicitly  defined  point  of  departure  from  which  changes  can 
be  proposed,  evaluated,  and  implemented.  The  baseline  evolves 
as  the  system  progresses  through  the  life  cycle  and  as 
changes  are  required.  The  importance  of  the  baseline  con¬ 
cept  is  that  it  provides  an  organized  structure  from  which 
to  evaluate  and  understand  the  changes. 
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Configuration  control  refers  to  the  procedures  by 
which  changes  to  baselines  are  proposed,  formally  processed, 
and  approved.  These  procedures  involve  standard  classes  and 
types  of  change  proposals,  as  well  as  formal  mechanisms  for 
review,  evaluation,  approval,  and  authorization  for  imple¬ 
menting  the  proposed  changes. 

Configuration  accounting  refers  to  the  reporting 
and  documenting  activities  involved  in  knowing  the  status 
of  various  system  baselines  at  all  times  during  the  system 
life  cycle.  For  Operating  Information  Systems,  it  is 
principally  a  matter  of  maintaining  a  record  of  and  reporting 
the  status  of  specifications,  associated  documents,  and 
proposed  changes. 

Configuration  Management  Documentation  and  Procedures 

While  the  purpose  of  configuration  management  is  to  con¬ 
trol  system  elements  (as  distinguished  from  data  or  services), 
the  management  process  itself  is  principally  a  matter  of 
accomplishing  documentation  and  establishing  procedures. 

As  indicated  above,  technical  specifications  are  the  principal 
substance  of  the  configuration  identification  process. 
Configuration  control  and  accounting  are  accomplished  by 
means  of  standard  forms  and  reports.  Account  must  also  be 
taken  of  technical  manuals  and  other  documents  prepared  for 
the  using  organization,  because  their  contents  are  sensitive 
to  changes  in  computer  program  configuration.  This  is 
particularly  true  in  the  case  of  complex  information 
systems . 

Hence,  configuration  management  and  its  sub-processes 
can  be  represented  as  a  structure  of  principal  documents 
and  the  standard  procedures  associated  with  those  documents. 
This  structure  is  illustrated  in  Figure  V.2,  which  shows: 

.  the  specifications  -  which  are  the  baselines 
that  are  defined  and  managed; 

.  the  dependent  procedural  data  -  in  the  form  of  hand¬ 
books  or  manuals;  and 

.  the  set  of  forms  and  reports  -  which  serve  as 
tools  for  control  and  accounting. 

Events  are  related  in  a  general  way  to  phases  of  the  system 
life  cycle.  Configuration  management  begins  during  the 
requirement  definition  segment  with  issuance  of  the 
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Operating  Information  System  Specification  and  expands 
during  the  system  development  segment;  it  is  maintained 
throughout  the  system's  operational  life. 

Three  baselines  are  established  at  successive  times 
during  development.  However,  an  earlier  baseline  is  not 
replaced  by  a  later  one,  because  each  serves  a  different 
function.  Once  established,  all  are  maintained  until 
the  system  is  deleted  from  the  inventory.  The  three 
baselines  are  shown  in  the  system  life-cycle  flow  chart 
in  Section  III. 

System  Testing 

Information  system  tests  are  divided  into  three  classes: 
qualification  tests,  system  tests,  and  pilot  tests.  These 
tests  are  necessary  to  ensure  that  the  system  will  meet  its 
requirements  when  it  is  actually  implemented. 

Qualification  Tests 


The  qualification  test  is  used  to  check  the  computer 
program’s  satisfaction  of  the  design/performance  requirements 
of  the  "design  to"  specification.  The  test  must  ensure  that 
all  the  system's  functional  requirements  have  been  translated 
into  computer  program  components.  The  qualification  testing 
program  is  divided  into  two  major  classes  of  te:  ts:  pre¬ 
liminary  qualification  tests  (PQT)  and  formal  q\  'lification 
tests  (FQT) . 

Preliminary  Qualification  Testing.  Prelimir  ry 
qualification  tests  are  designed  to  verify  the  pe  formance 
of  individual  components  prior  to  an  integrator  r. -^l 
qualification  of  the  complete  computer  program.  Even 
though  the  tests  are  preliminary  in  nature,  they  provide 
check  points  for  monitoring  the  designer's  progress  towards 
meeting  design  objectives  and  for  verifying  detailed  per¬ 
formance  characteristics  which,  because  of  sheer  numbers  and 
complexity,  may  not  be  feasible  to  verify  in  their  entirety 
during  formal  qualification  testing.  The  PQT  phase  is  con¬ 
ducted  incrementally  by  components  in  the  same  manner  as 
the  Detailed  Design  Review  (DDR).  Figure  V.3  depicts 
the  relationship  between  the  DDR  and  the  test  program.  The 
cross-hatched  blocks  in  Figure  V.3  indicate  coding  of  in¬ 
dividual  computer  program  components.  The  preliminary 
qualification  tests  are  modular,  and  a  "building  block" 
effect  occurs  as  testing  progresses. 
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Formal  Qualification  Testing.  Formal  qualification 
tasts  are  aimilar  to  tha  PQTs  conducted  on  program  com¬ 
ponents.  They  differ  in  that  the  FQTs  test  complete 
application  programs  prior  to  the  start  of  system  testing, 
while  PQTs  test  only  individual  components.  The  FQT 
represents  the  formal  qualification  of  a  computer  program. 
These  tests  illustrate  the  application  program's  satisfaction 
of  the  application  specification  requirements. 

System  Tests 

System  tests  are  performed  to  demonstrate  that  all  the 
system  elements  function  together  to  satisfy  the  performance 
requirements  given  in  the  system  specification.  Generally, 
system  tests  are  designed  to  evaluate  all  five  elements  of 
the  system  (i.e.,  computer  programs,  equipment,  facilities, 
personnel,  and  procedural  data).  These  tests  usually  pro¬ 
gress  from  subsystem  tests  to  system  tests  and  are  conducted 
Ly  the  Army  in  an  environment  that  is  as  near  the  expected 
operational  environment  as  possible. 


Pilot  Tests 

The  pilot  test  is  a  test  of  the  whole  system  in  an 
actual  operational  environment.  It  is  used  to  determine 
whether  the  system  satisfies  the  information  requirements 
under  real  operating  conditions  with  actual  operating 
personnel.  The  pilot  test  is  the  final  evaluation  of 
the  system  before  it  becomes  operational. 


VI.  MISD  ACTIVITIES 


This  section  explains  how  MISD's  internal  operations 
are  accomplished  using  the  information  and  techniques 
described  in  the  preceding  sections.  The  operations  are 
presented  in  terms  of  the  functional  activities  that 
make  up  the  day-to-day  management  of  AMIS  and  its  components. 
These  activities  already  exist  in  some  form  within  the 
present  MISD  organization,  although  the  organization  is 
not  specifically  structured  according  to  the  activities 
described  herein.  The  existence  of  these  activities  permits 
the  recommended  capabilities  to  be  developed  within  the 
practical  limitations  of  available  resources  and  to  be 
implemented  incrementally. 


Procedural  Activities 


MISD’s  activities  are  related  to  the  major  segments 
of  a  system's  life  cycle  in  Figure  VI. 1.  This  grouping  also 
reflects  the  changing  nature  of  systems.  As  indicated  in 
Figure  VI. 1,  MISD  planning  is  a  root  activity  that  is 
basic  to  all  subsequent  life-cycle  segments. 

The  MISD  procedural  activities  listed  in  Figure  VI. 1 
accomplish  the  major  functions  of  the  Management  Information 
Systems  Directorate.  These  functions  are  necessary  to 
enable  MISD  to  achieve  its  objectives,  which  are: 

.  to  develop  overall  AMIS  goals  and  plans; 

.  to  review  and  evaluate  MIS  requirements  and 
improvement  plans; 

.  to  guide  MIS  improvement  projects; 

.  to  monitor  MTS  operations; 

.  to  provide  guidance  on  ADPE  requirements; 

.  to  promote  the  use  of  standards;  and 

.  to  promote  the  use  of  improved  MIS  management 
practices . 

A  jystem  existing  in  the  form  of  a  requirement  differs 
from  the  same  system  in  the  development  stage.  This  system 
usually  is  altered  again  when  it  becomes  operational.  The 
differences  are  reflected  in  information  on  the  kinds  o‘ 
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MISD  Procedural  Activity 

Corresponding  Life-Cycle  Segment 

Planning 

Requirement  Definition 

Project  Approval 

Requirement  Definition 

Project  Management 

System  Development 

Monitoring  of  Operations 

Operation 

Other  Operations 

.  Promotion  of  Standards 

.  One-Time  Studies 

.  Procedure  Development 

.  Headquarters  MIS  Support 

General 

FIGURE  VI. 1 
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decisions  and  information  needed  and  on  the  numbers  and 
type  of  personnel  involved.  In  recognition  of  this,  MISD 
management  practices  must  adjust  as  a  system  evolves. 

The  following  descriptions  of  MISD  procedural  activities 
explain  the  changing  role  of  MISD  during  the  life-cycle 
process.  These  descriptions  are  amplified  in  Appendix  C, 
Procedural  Checklists.  The  checklists  consist  of  points 
MISD  must  consider  when  reviewing  and  evaluating  specific 
documents. 

Planning 

The  traditional  planning  function  is  comprised  of  the 
following: 

.  setting  goals; 

.  deciding  on  the  strategy  to  use  in  achieving 
those  goals;  and 

.  devising  a  scheduled  sequence  of  events  (tasks) 
to  achieve  the  goals. 

As  a  senior  staff  organization,  MISD  is  less  direct 
in  its  planning,  the  functions  of  which  are: 

.  to  formulate  overall  AMIS/Army  goals  and 
policies; 

.  to  provide  guidance  on  developing  better  informa¬ 
tion  capabilities  and  to  influence  the  planning 
and  development  processes  of  those  who  develop 
and  improve  systems;  and 

.  to  coordinate  ♦'he  more  detailed  planning  of 
various  improvement  efforts  within  the 
requirements  of  AMIS. 

The  formulation  of  goals  and  the  ether  elements  of 
MISD  planning  are  analagous  to  those  of  organisations  more 
directly  involved  in  development  or  operations.  MlSD's 
planning  activities  join  it.'  two  control  mechanisms: 
approval  of  goals  and  assignment  of  resources.  At  the 
same  time,  the  innovations  related  to  improvements  remain 
with  design  agencies  and  the  more  operational  organizations . 


VI. 3 

-  —  —  ■—  /h*?f  l/iV*.V4  /  ti  IWi"  *  f*‘  H  \  t  t-  — 


A  focal  point  for  planning  information  Is  a  master 
plan,  which  contains  approved  MIS  programs  for  satisfying 
information  needs.  This  plan  contains  time-phased  data 
on  all  AMIS  activities,  thus  providing  the  best  picture  of 
overall  Army  information  services.  .•’*«  ter  plan  links 

MISD  planning  with  the  budgeting  process.  A  description  of 
the  kinds  of  information  in  this  plan  is  given  in  the  latter 
part  of  this  section. 

The  items  listed  below  are  brief  summaries  of  the 
functions  of  the  procedural  taskwork  that  takes  places 
within  MISD  during  the  planning  phase.  These  task  functions 
are: 

.  to  remain  aware  of  the  present  MIS  situation 
with  regard  to  information  services,  capabilities, 
and  costs.  This  includes  determining  when 
resources  (new  or  being  released)  are  available 
for  assignment; 

.  to  categorize  the  structure  of  Army  Management 
Information  Systems  in  a  form  that  is  useful 
for  management  and  control,  but  relatively 
independent  of  the  technical  services  provided; 

.  to  provide  a  link  between  information  system:, 
planning,  AMIS,  and  the  Army  PPBS ; 

.  to  determine  information  requirements  of  HQDA; 

.  to  organize  and  coordinate  the  for 

improving  AMIS; 

.  to  develop  procedures  for  and  manage  the 
generation  of  a  master  plan  for  projecting 
requirements  and  resources  necessary  for 
disciplined  design,  development,  testing, 
and  operation; 

.  to  formula*#  policy  guidance  for  structuring, 
managing,  and  improving  the  AMIS,  both  as  an 
input  to  the  master  plan  and  for  organizations 
providing  inputs  to  the  plan; 

.  to  develop  Army  methodology  on  planning  and 
managing  development  projects,  including 
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specification  of  what  constitutes  complete¬ 
ness.  This  effort  must  be  closely  related  to  the 
activity  of  project  progress  monitoring; 

.  to  participate  in  the  review  and  evaluation  of 
RSR,  RSS ,  and  OISR  with  regard  to  the  master 
plan.  These  documents  must  reflect  mature, 
well  reasoned  approaches  to  providing  services 
that  fulfill  defined  requirements.  A  significant 
part  of  this  procedure  will  depend  on  subjective/ 
qualitative  criteria; 

.  to  assess  the  impact  of  system  changes  on  DPI  and 
system  operations  and  vice  versa; 

.  to  develop  procedures  for  ensuring  the  financial 
integrity  of  improvement  projects  and  proposed 
systems  by  coordinating  and  interfacing  system 
plans  with  the  annual  budgeting  cycle.  This 
includes  the  processing  or  coordination  of 
PCRs  and  providing  advice  on  financial  problems; 

.  to  determine  priorities  among  changes  proposed  for 
improving  AMIS  and  to  use  the  results  of  this 
determination ,  in  -conjunction  with  information 
on  resource  availability,  to  allocate  resources; 

.  to  coordinate  AMIS  data  communications  require¬ 
ments  and  planning  with  Assistant  Chief  of  Staff 
for  Communications-Electronics ; 

.  to  coord-  'te  with  DCSPERS  the  training  of 

competen  ^formation  specialists  and  to  assist 
in  the  development  of  projections  on  instructional 
needs  and  modifications,  MOS  considerations,  etc; 

.  to  promote  cost-effective  practices;  and 

.  to  promote  the  standardization  of  procedures  and 
interfaces . 

Project  Approval 

The  function  cf  this  activity  art  is  to  decide  whether 
to  approve  the  development  of  system  improvement  projects. 
Many  of  the  decisions  are  not  absolute.  An  approval  is 
often  qualified  by  directing  a  shift  in  the  content,  time 
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frame,  or  direction  of  the  development  process.  MISD 
reaches  the  decisions  by  reviewing  and  evaluating  documents 
and  remaining  in  close  contact  with  the  organizations  in¬ 
volved. 

Review  and  evaluation  of  projects  occurs  at  certain 
critical  design  points.  In  a  real  sense,  the  projects 
under  consideration  are  the  systems  themselves,  as  they 
exist  at  that  particular  point  in  time.  The  proposed 
project  designs  represent  the  objectives  of  the  develop¬ 
ment  organizations.  By  its  participation  in  the  approval 
process,  MISD  is  able  to  influence  project  goals  while  they 
are  being  formulated.  This  is  an  important  part  of 
MISD's  control  apparatus.  The  basic  decisions  reached  at 
each  point  of  approval  are  whether  future  incremental  costs 
will  be  worth  the  benefits  and  what  action  should  be 
taken.  Similar  decisions  must  be  made  throughout  the 
life  cycle. 

The  review  and  evaluation  activities  require  the 
processing  of  certain  life-cycle  documents,  which  are 
submitted  to  MISD  during  the  requirement  definition 
segment  of  the  system  life  cycle  and  are  described  in 
Appendix  A.  Appendix  C  gives  a  detailed  explanation  of 
MISD  processing  of  each  of  these  documents.  The  decisions 
reached  v ^  MISD  as  a  result  of  the  evaluation  are  promul¬ 
gated  through  directives.  The  MISD  approval  process  is 
composed  of  two  sets  of  tasks. 

.  MISD  first  reviews  and  evaluates  system  requirements 
and  system  specification  documentation  for  proposed 
improvement  projects.  It  then  decides  whether 
development  should  proceed,  be  modified,  be  delayed, 
or  be  halted.  Evaluations  consider  the  solidness 
of  the  concepts,  the  competency  of  development 
organizations,  the  availability  of  resources,  the 
cost  effectiveness  of  the  system,  and  the  impact 
upon  other  AMIS  plans  and  objectives. 

.  After  completing  the  first  set  of  tasks,  MISD 
promulgates  directives  that  give  the  results 
of  reviews  and  evaluations,  assign  responsibilities, 
and  provide  guidance  for  proceeding  with  the  particular 
development  efforts. 


Project  Management 


MISD  schedules  approval  sessions  throughout  the 
development  phases  of  systems.  However,  the  emphasis  is 
shifted  so  that  tha  monitoring  of  progress  is  the  primary 
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purpose  of  the  later  sessions.  MISD  must  make  certain 
that  design  objectives  are  accomplished  within  the  limits 
of  available  resources.  To  perform  this  important  task, 

MISD  relies  on  the  project  reports  submitted  by  monitoring 
and  developing  organizations.  These  reports  were  described 
in  Section  V.  Appendix  B  provides  examples  of  a  report 
hierarchy . 

Project  management  reports  submitted  to  MISD  are 
used  to  compare  actual  progress  with  planned  accomplish¬ 
ment  in  the  areas  of  cost,  performance,  and  scheduling. 

They  allow  early  identification  of  problems  needing  MISD 
attention,  as  we.1!  as  control  of  the  system  design.  The 
latter  is  partially  accomplished  by  examining  the  documen¬ 
tation  to  make  sure  that  the  basic  system  development 
steps  are  completed.  The  reports  also  allow  MISD  to 
judge  the  quality  of  the  accomplishments  and  to  see  that 
configuration  management  principles  with  their  control  over 
the  changes  affecting  performance  are  adhered  to.  The 
latter  is  of  great  importance  because  the  management  prin¬ 
ciples  provide  discipline. 

In  this  regard,  it  is  important  to  remember  that  the 
systems  being  produced  are  not  physical  things  that  can 
be  compared  with  requirements  to  determine  adequacy.  They 
are  still  essentially  conceptual  in  nature.  Examination 
of  documentation  (e.g.,  progress  reports,  test  results, 
production  outputs,  etc.)  and  familiarity  with  the  developing 
organizations  are  the  only  ways  to  "know"  how  the  project 
is  doing. 

The  other  function  of  MISD  project  management  is  de¬ 
ciding  how  to  handle  problems  when  something  wrong  is 
detected  or  when  reorientation  is  needed.  This,  of  course, 
depends  on  MISD's  actual  role  and  on  the  nature  of  the 
situation.  Most  problems  are  caused  by  shortages  of  men, 
money,  time,  or  facilities.  In  these  instances,  MISD's 
role  usually  involves  coordinating  efforts  to  supply  what 
is  needed.  This  is  accomplished  by  analyzing  trade-offs, 
judging  the  impact  of  changes  upon  other  projects,  and 
objectively  evaluating  the  systems  competing  for  scarce 
resources.  Most  importantly,  MISD  substantiates  the  need 
for  the  recommended  solutions  to  gain  approval  of  the 
solutions .  The  importance  of  information  in  this  process 
is  manifest. 

MISD's  most  difficult  problem  occurs  when  problems 
exist  in  meeting  performance  specifications.  Its  role  is 
to  pinpoint  these  problems  as  early  as  possible  and  focus 
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command  and  management  attention  on  resolving  them.  Of 
greater  importance  is  MISD's  task  of  precluding  or  diminish 
ing  the  occurrence  of  performance  problems  through  improve¬ 
ments  to  system  development. 

Operations  Monitoring 

MISD  is  not  vitally  interested  in  the  conduct  of 
system  operations.  Its  interest  in  operations  is  limited 
to  understanding  the  AMIS  structure,  being  able  to  estimate 
accurately  the  costs  of  providing  Army  information  services 
and  ensuring  the  continuity  of  system  management.  To 
accomplish  this,  MISD  needs  historical  resource  data. 

Knowledge  of  actual  resource  costs  is  used  by  MISD 
in  gauging  the  accuracy  of  planning  information.  This  is 
important  because  cost  schedules  for  proposed  information 
systems  are  often  inaccurate.  The  data  also  aids  in  the 
preparation  and  substantiation  of  budgets  and  PCRs .  The 
same  is  true  of  requests  for  ADPE.  Thus,  the  historical 
data  is  used  by  MISD  primarily  as  an  input  to  other 
activities . 

However,  the  system  management  process  is  also  of 
interest  to  MISD  during  a  system's  operation  segment.  MISD 
needs  assurance  that  responsibilities  remain  assigned 
and  that  configuration  management,  with  its  control  over 
changes,  is  an  ongoing  activity.  This  interest  is  passive 
in  nature,  because  system  management  practices  are  arranged 
by  directive. 

MISD  Information  Requirements 

MISD's  success  in  actively  managing  AMIS  depends  on 
its  ability  to  make  decisions  and  to  know  what  is  going  on. 
To  make  those  decisions  meaningful,  to  develop  plans,  and 
to  carry  on  the  other  activities  just  outlined,  certain 
information  is  required.  Figure  VI . 2 ,  MISD  Information 
Inputs,  relates  the  needs  to  the  procedural  activities 
just  discussed  by  showing: 

.  types  of  organizations  providing  information; 

.  categories  of  information  that  are  available 
to  or  received  by  MISD; 

.  MISD  procedural  activities ; 
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Source 

Organization 

Information 

Category 

Frequency  of 
Input 

Principal  User 
(Procedural  Activity) 

RDA  via  MA 

Project  plans 

Annually , 
Unscheduled 

Planning,  Approval 

RDA  &  MA,  via 
COA 

MIS  plans 

Annually , 
Unscheduled 

Planning 

DPI  &  Commands, 
via  COA 

DPI  plans 

Annually , 
Unscheduled 

Planning 

DPI  via  COA 

Descriptions 
of  DPI  capa¬ 
bilities 

Initially , 
Unscheduled 

Planning 

RDA  via  MA 

OIS  and 

GS.RS  defini¬ 
tion 

Unscheduled 

Planning , 

Approval 

MISD,  MA  & 
Commands 

Narrative 
plans  of  AMIS 
organizations , 
facilities,  & 
systems 

Annually 

Planning 

Varied 

Descriptions 
and  plans  of 
study  (or  man¬ 
agement  im¬ 
provement) 
efforts 

Annually , 
Unscheduled 

Planning 

RDA  via  MA 

Project/study 
progress  and 
configuration 
management 
reports 

Monthly , 
Quarterly 

Project  Monitoring, 
Operations  Moni¬ 
toring 

DPI  via  COA 

DPI  actual 
operations 
statistics 

Quarterly 

Operations 

Monitoring 

FIGURE  VI. 2 

MISD  INFORMATION  INPUTS 
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.  frequency  requirements  for  input  of  information; 
and 

.  principal  procedural  activity  interested  in  the 
information . 

Some  of  the  information  received  by  MISD  is  used  to 
generate  analytic  and  summary  reports.  Whether  the  use  of 
an  Operating  Information  System  is  required  depends  on  the 
data  volumes,  frequencies,  sorting,  and  retrieval  charac¬ 
teristics.  The  development  of  an  OIS  for  MISD  appears 
necessary,  because  much  of  the  data  can  be  handled  more 
easily  and  can  be  used  to  provide  more  effective  response 
in  a  mechanized  form. 

The  information  in  Figure  VI. 2  is  directly  related  to 
the  needs  of  life-cycle  management.  The  descriptions  of 
information  categories  in  the  following  paragraphs  should 
be  viewed  within  the  context  of  that  ongoing  process. 

Information  Inputs  to  MISD 

Project  Plans.  Plans  for  improvements  to  AMIS  com¬ 
ponents  are  coordinated  and  summarized  before  they  are 
included  in  the  master  plan.  This  planning  information  is 
part  of  the  annual  budget  cycle  and  also  part  of  the 
process  by  which  improvement  projects  are  cleared  for 
implementation.  The  information  consists  of  narrative 
descriptions  of  goals,  a  work  breakdown  structure, 
cost,  schedule,  and  performance  data  for  each  included 
project. 

MIS  Plans.  These  plans  describe  resource  requirements, 
including  financial  data.  Budget  data,  including  identifi¬ 
cation  of  appropriations  and  DPIs,  is  particularly  important 
MISD  also  has  a  need  to  be  informed  of  Budget  Program 
Change  Requests.  The  quantitative  data  is  extractable 
from  DPI  plans  if  the  plans  include  a  breakdown  according 
to  OIS. 

DPI  Plans.  This  data  consists  of  an  expanded  version 
of  that  submitted  in  accordance  with  AR  18-3.  It  includes 
an  additional  breakdown,  which  shows  cost,  schedule,  and 
performance  by  designated  OIS.  Budget/appropriation  data 
is  also  added. 

Descriptions  of  DPI  Capabilities.  This  data  describes 
and  categorizes  each  facility  by  equipment,  languages, 
and  manpower. 
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OIS  and  G&RS  Definition  Documents.  These  are  RSR, 

RSS ,  OISR,  OISS,  and  OISDP,  as  explained  in  Appendix  A. 

They  describe  and  specify  reporting  and  component  operating 
systems  as  they  evolve. 

Narrative  Plans  of  AMIS  Organizations,  DPI  Systems. 

In  addition  to  the  more  quantifiable  data,  MISD  needs 
narrative  descriptions  of  MIS  plans  for  HQDA  and  major 
commands.  These  plans  state  overall  goals  and  efforts, 
including  the  needs  for  management  and  analytical  studies, 
the  direction  of  projects,  significant  changes  and  problem 
areas,  and  personnel,  communications,  and  ADPE  requirements. 
This  information  is  used  by  MISD  in  laying  the  groundwork 
for  future  systems,  in  drawing  up  the  master  plan,  and  in 
determining  the  impact  the  plans  submitted  have  on  the 
Army . 


Project/Study  Progress  and  Configuration  Management 
Reports .  This  information  is  described  in  Appendix  B. 

The  reports  show  project  status,  i.e.,  actual  versus 
planned  resource  expenditures,  accomplishment  of  milestones, 
cost,  schedule,  and  performance  data,  problems,  and  changes. 

DPI  Actual  Operations  Statistics.  This  data  corresponds 
to  that  submitted  in  accordance  with  AR  18-3.  As  with  the 
DPI  planning  information,  it  includes  cost,  schedule,  and 
performance  data  for  each  designated  OIS.  Identification 
of  budget  appropriation  is  also  useful. 

MISD  Generated  Information 

The  information  inputs  just  described  are  used  in 
many  ways.  However,  they  require  some  preparation  before 
they  can  be  used  by  the  MISD  staff.  As  shown  in  Figure 
VI. 3,  MISD  Generated  Information,  the  information  is  classi¬ 
fied  and  placed  in  at  least  four  categories. 

Inventory  Lists.  The  following  are  needed  to  describe 

AMIS : 


.  project  inventory  -  by  organization  and  by 
budget  program; 

.  reporting  systems  -  showing  component  OISs; 

.  ADPE  inventory  -  by  organization  and  by  equipment; 

.  DPI  inventory  -  by  organization; 

.  personnel  inventory  -  by  skill  and  by  organization. 
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Source 

Organization 

Information 

Category 

Suggested 

Input 

Frequency 

Principal  User 
(Procedural  Activity) 

MISD 

Inventory 

Lists 

Annually, 

Quarterly 

All 

* 

1 

MISD 

MIS  Financial 
Analyses 

Annually , 
Unscheduled 

Planning,  Approval, 
Project  Monitoring 

MISD 

Project/Study 

Management 

Summaries 

Monthly, 

Quarterly 

Project  Monitorinc, 
Operations 

Monitoring 

MISD 

Master  Plan 

Annually 

Planning,  Approval 

FIGURE  VI. 3 


MISD  GENERATED  INFORMATION 


MIS  Financial  Analysis.  This  information  is  needed 
for  impact  analysis,  cost-effectiveness  studies,  system 
design,  budget  preparation,  and  detection  of  problems, 
especially  of  potential  cost  overruns.  The  primary  data 
elements  necessary  are  dollars  and  manpower,  in  the 
following  areas: 


.  projects  -  by  budget  program; 

.  organizations  -  by  appropriations;  and 

.  appropriations  -  by  organization  and  by  project. 

Project/Study  Management  Summaries.  These  reports 
combine  project  progress  and  status  reports  and  summarize 
them  for  use  in  monitoring  and  problem  detection. 

Master  Plan.  The  information  in  the  master  plan 
performs  the  following  three  functions. 

.  It  provides  a  tool  for  controlling  changes  to  AMIS. 

.  It  provides  an  overview  of  AMIS  as  an  entity  for  use 
as  a  basis  for  creating  improvements. 

.  It  provides  guidance  to  organizations  responsible 
for  accomplishing  improvements  and  managing 
operations . 

The  plan  contains  narrative  descriptions  of  goals, 
methodology,  and  new  directions  for  up  to  five  fiscal 
years.  Included  are  sections  for  major  commands,  HQDA 
staff  agencies,  and  other  organizations.  It  also  provides 
guidance  to  these  organizations  to  aid  in  the  accomplish¬ 
ment  of  their  plans. 

Tabular  data  contains  approved  plans  for  projects, 
reporting  systems,  organizations'  DPIs,  and  other  needed 
summaries.  Again,  a  five-year  period  is  covered,  but  only 
plans  for  approved  programs  are  included.  Some  activities 
are  aggregated  rather  than  described  individually;  this  is 
done  to  limit  the  size  of  the  master  plan  by  including 
only  the  more  important  cost  centers.  The  more  important 
tabular  summaries  contain  reporting  system  plans  as 
collections  of  their  component  OIS  and  DPI  plans  to  con¬ 
cisely  depict  their  time-phased  resource  schedules.  The 
master  plan  also  links  systems  planning  directly  to  the 
program/budget  process. 
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The  following  items  comprise  the  master  plan  just 
described: 

.  narratives: 

.  AMIS  (general  Army)  plans; 

.  command  (organizational)  plans; 

.  Guidance  and  Reporting  System; 

.  headquarters  (functional)  guidance; 

.  project  plans/schedules: 

.  identification; 

.  cost; 

.  schedule; 

.  performance; 

.  G&RS/OIS  plans/schedules: 

.  identification; 

.  cost; 

.  schedule; 

.  performance; 

.  commandj?  (cost,  manpower  schedules): 

.  DPI; 

.  OIS ; 

.  ADPE ; 

.  summary  of  GfcRS  resources: 

.  cost/G4RS  ; 


.  MPR/GfcRS ; 


r 


.  contractor  schedules: 


.  projects; 

.  operations; 

.  studies; 

.  changes  to  ADPE  (for  COA) : 

.  by  model; 

.  by  DPI; 

.  by  utilization; 

.  personnel  summary; 

.  communications  summary;  and 
.  budget/program  guidance. 
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VII.  MANAGEMENT  CRITERIA 


The  Management  Information  Systems  Directorate's  task 
of  improving  the  overall  quality  of  AMIS  requires  accurate 
evaluations  of  individual  management  information  systems. 

These  evaluations  are  made  by  staff  members  who  have  no 
intimate  knowledge  of  the  functions  or  purposes  of  the  sys¬ 
tems.  Therefore,  evaluation  criteria  that  correctly  reflect 
system  performance  are  essential.  The  reliability  of  these 
criteria  is  especially  important  because  the  evaluations 
result  in  recommendations  for  system  modifications,  objec¬ 
tives,  and  resource  expenditures.  Before  the  personnel  re¬ 
sponsible  for  individual  management  information  systems  can 
accept  these  recommendations  as  authoritative  and  worthwhile, 
they  must  accept  the  evaluation  criteria  as  reliable  and 
relevant  to  system  performance.  If  the  criteria  are  not 
accepted,  MISD  cannot  effectively  administer  its  control 
function . 

Although  MISD  improves  AMIS  to  some  degree  by  providing 
a  life-cycle  methodology,  AMIS  is  improved  principally  by 
MISD  decisions  on  resource  expenditures  and  system  objectives. 
Each  MISD  decision  is  unique,  because  each  system  is  differ¬ 
ent  and  each  system  changes  as  it  develops.  However,  the 
situations  with  which  MISD  deals  share  important  common 
characteristics.  Furthermore,  many  are  related  by  the  con¬ 
text  of  life-cycle  management.  Because  of  this,  the  devel¬ 
opment  of  procedures  for  use  in  determining  values  and  reach¬ 
ing  sound  decisions  is  possible.  These  procedures  provide 
the  framework  necessary  for  evaluations  of  complex  systems, 
which  involve  a  large  number  of  variables  and  dynamic  values, 
any  one  of  which  could  be  critical  to  success.  The  framework 
is  also  useful  in  teaching  new  staff  members  how  to  conduct 
an  evaluation  or  a  review. 


Cost-Effectiveness  Concepts 

Setting  Objectives 

One  of  the  objectives  of  the  MISD  decision-making  pro 
cess  is: 

.  to  obtain  maximum  system  performance  from  a 
specified  amount  of  resources;  or 

.  to  obtain  a  specified  level  of  system  perfor¬ 
mance  for  the  least  possible  resource  expen¬ 
diture. 
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When  MISD  studies  AMIS  for  the  purpose  of  setting  overall 
policy,  priorities,  or  guidelines,  it  places  more  emphasis 
on  the  first  alternative.  When  studying  a  particular  proj¬ 
ect,  MISD  places  more  emphasis  on  satisfying  requirements 
at  the  least  cost.  However,  neither  objective  is  exclusively 
used  in  either  situation. 

The  important  parts  of  any  evaluative  process  are  system 
performance  objectives  and  the  limitations  or  costs  involved. 
To  conduct  evaluations  and  reach  sound  decisions,  it  is  nec¬ 
essary  to  understand  both.  This  involves  regarding  either 
performance  or  cost  as  a  constant  for  evaluation  purposes. 
When  MISD  understands  the  objectives  and  limitations  or  costs 
of  a  system,  it  develops  criteria  for  use  in  gauging  the 
value  of  that  system. 

Defining  Criteria 

In  the  general  sense,  a  criterion  is  a  measure  that  is 
used  as  a  yardstick  for  comparison  and  decision-making .  In 
their  most  desirable  form,  criteria  are  numbers  that  can  be 
compared  with  actual  measurements.  For  instance,  if  the 
criteria  for  an  acceptable  query  response  time  for  a  pro¬ 
posed  OIS  is  "less  than  one  minute,"  it  is  obvious  that  an 
OIS  with  a  response  of  30  seconds  meets  the  criteria.  There¬ 
fore,  it  appears  that  the  use  of  an  exhaustive  set  of  perfor¬ 
mance  specifications  is  all  that  is  necessary  to  determine 
whether  a  system  or  proposed  change  is  adequate.  However, 
though  such  sets  are  useful,  they  are  not  sufficient  for 
MISD's  purpose  for  the  following  major  reasons: 

.  some  criteria  cannot  be  adequately  quantified 
(e.g.,  the  value  of  having  or  not  having  infor¬ 
mation)  ; 

.  the  accuracy  of  data  (e.g.,  projected  performance, 
such  as  query  response  times)  is  not  obvious; 

.  assumptions  about  user  requirements  may  not  be 
understood  or  may  not  be  valid; 

.  cost  estimates  may  be  low,  and  if  their  deriva¬ 
tions  are  not  known  to  evaluators,  their  flaws 
will  be  hard  to  detect; 

.  comparisons  must  be  made  between  systems  which 
do  different  things  but  which  compete  for  scarce 
resources  (e.g.,  money,  men,  equipment,  etc.); 
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.  the  competency  of  the  individuals  and  organiza¬ 
tions  involved  is  an  important  variable  that 
must  be  judged  or  assumed; 

.  some  system  requirements  submitted  as  constants 
may  change ,  or  if  stated  as  averages  (e.g., 

1,000  file  changes  per  month),  may  not  reflect 
major  fluctuations  from  those  averages; 

.  the  success  of  a  proposed  improvement  project 
depends  on  many  uncertainties; 

.  some  requirements  are  approximations  based  on 
other  approximations; 

.  ratios  are  used  to  relate  performance  to  cost, 
thereby  preventing  the  absolute  values  from 
being  visible  to  the  staff  evaluator;  and 

.  important  intangibles  or  uncertainties  may  be 
deleted  or  ignored  because  they  cannot  be  ade¬ 
quately  specified  or  measured,  thus  resulting 
in  a  lack  of  flexibility  in  the  designs  for 
different  situations. 

A  simplified  example  of  the  questions  MISD  faces 
involves  the  proposed  acquisition  of  an  input/output  device 
for  a  time-shared  system.  Several  factors  must  be  consid¬ 
ered  in  making  a  decision.  For  instance,  the  maximum  trans¬ 
mission  rate  of  the  device  may  not  be  as  important  as  its 
ease  of  use.  A  high  transmission  rate  may  result  in  reduced 
accuracy.  Furthermore,  maintenance  may  be  a  problem  if 
engineers  are  not  readily  available  or  if  the  device's  com¬ 
ponents  are  not  reliable.  The  time  and  expense  involved  in 
designing  record  formats  is  also  an  important  factor. 

Finally,  operators  may  need  a  new  kind  of  training  to  over¬ 
come  psychological  barriers  erected  as  a  result  of  the  acqui¬ 
sition  of  such  a  device. 

It  is  obvious  that  MISD  does  not  accomplish  this  level 
of  analysis.  Evaluation  of  such  factors  is  the  responsibil¬ 
ity  of  the  MA  and  RDA.  However,  MISD  does  make  a  decision 
based  on  the  information  contained  in  the  documents  submitted 
by  the  MA  and  RDA,  For  the  more  important  projects,  MISD 
staff  members  become  more  involved  in  the  actual  research  and 
do  not  rely  solely  on  reviewing  the  MA  and  RDA  documents. 
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Evaluation  Procedures 


Two  factors  dictate  the  kinds  of  criteria  used  by  MISD 
in  evaluating  AMIS  and  proposed  improvements:  the  accomplish¬ 
ments  desired  and  the  types  of  decisions  required.  The  first 
factor,  the  accomplishments  desired,  involves  the  scope  of 
the  study,  i.e.,  the  necessary  measurements  and  level  of 
detail.  AMIS  studies  look  at  the  macro-view.  These  studies 
are  probably  the  most  subjective,  stressing  planning  for  the 
future.  They  concentrate  on  aggregates  of  resources  and 
gross  requirements  for  accomplishing  MISD  goals.  Studies  on 
a  particular  G&RS  are  more  detailed  in  this  perspective,  but 
still  stress  questions  and  approaches  for  use  in  satisfying 
requirements.  Studies  of  individual  OISs  are  the  most  de¬ 
tailed  and  quantitative. 

The  second  factor  affecting  the  kinds  of  criteria  used 
is  the  kinds  of  decisions  (actions)  required  of  MISD.  This 
varies  with  the  subject's  life-cycle  phase  and  priorities, 
and  with  the  role  MISD  plays  in  relation  to  the  subject. 

During  the  requirement  definition  segment,  planning  is  long- 
range  and  conceptual.  Decisions  on  setting  and  approving 
goals  are  most  important.  MISD's  role  may  be  to  review  and 
advise  rather  than  to  approve  or  take  action.  During  the 
system  development  segment,  emphasis  is  on  ensuring  adherence 
to  plans  and  on  early  detection  and  elimination  of  problems 
impeding  progress.  Few  active  decisions  are  required  of  MISD 
during  the  operation  segment. 

Section  VI  and  the  procedural  checklists  in  Appendix  C 
contain  evaluation  guidelines  with  the  criteria  MISD  needs 
to  manage  systems.  The  procedures  directly  relate  to  system 
life-cycle  processes.  MISD's  internal  planning  activity  is 
included  as  well  as  steps  for  processing  important  documents. 
Processing  the  documents,  either  for  review  or  for  evaluation 
purposes,  offers  MISD  its  best  opportunity  to  promote  good 
engineering  and  management  practices  while  improving  AMIS. 

In  addition  to  affecting  system  content  and  development, 
MISD  staff  involvement  ensures  clear  communications  between 
users  and  technicians.  This  is  a  result  of  greater  emphasis 
on  preparation  and  planning  prior  to  the  expending  of  develop¬ 
ment  funds.  The  greater  emphasis  on  preparation  and  planning 
manifests  itself  in  clearer  specification  of  requirements  and 
systems  performance  in  terms  of  products  and  services.  Com¬ 
munications  are  also  enhanced  by  the  clarification  of  accom¬ 
plishment  and  cost  schedules.  Early  decisions  are  formally 
linked  and  reinforced  within  the  life  cycle  by  periodic  sub¬ 
missions  of  technical  and  progress  reports  so  that  status  and 
problems  are  visible  on  a  systemwide  basis. 
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The  criteria  guidelines  used  in  the  MISD  management 
process  are  explained  in  Appendix  C,  which  should  be  used 
in  conjunction  with  the  document  formats  in  Appendices  A 
and  B.  The  appendices  are  organized  for  direct  use  in  man¬ 
aging  information  systems  throughout  their  life  cycles. 

The  criteria  and  the  methodology  for  applying  them  to  reach 
the  best  decisions  are  extremely  important  to  the  task  of 
improving  the  quality  of  management  information.  They  do 
not  replace  the  use  of  judgment  in  MISD  decision-making; 
however,  they  reduce  the  uncertainties  involved,  improve  the 
quality  of  preparation  for  changes,  ensure  the  integrity  of 
the  concepts  on  which  the  systems  are  based,  and  aid  in  an 
early  detection  of  problems.  These  criteria  are  essential 
to  coping  with  AMIS  dynamics. 
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VIII.  IMPLEMENTATION  PLAN 


This  report  marks  the  conclusion  of  Peat,  Marwick, 
Livingston  &  Co.'s  taskwork  under  contract  DAHC  19-67-C-0052 . 
The  study  performed  by  PML  has  resulted  in  a  number  of 
promising  accomplishments.  Amonq  these  are  the  AMIS  classi¬ 
fication  scheme,  life-cycle  management,  and  resource  moni¬ 
toring.  Ancillary  support  activities'  contributions  in¬ 
cluded  aid  in  developing  a  draft  AR  18-xx  (Appendix  D)  and 
in  formulating  the  master  plan .  The  capability  require¬ 
ments,  procedural  guidelines,  and  systematic  approach  to 
upgrading  Army  management  information  systems  contained 
in  this  report  are  also  a  product  of  the  study  activities. 
They  comprise  the  system  designed  to  provide  the  Army  with 
sufficient  criteria  and  procedures  to  more  effectively 
manage  AMIS. 


As  stated  in  Section  I ,  promulgation  of  an  Army  Regu¬ 
lation  similar  to  that  in  Appendix  D  is  the  first  of  three 
stages  in  the  task  of  improving  MISD's  management  capabili¬ 
ties.  This  section  presents  PML's  approach  to  the  next 
stage,  i.e.,  implementation  of  the  concepts  developed  dur¬ 
ing  the  study.  PML  believes  the  following  three  steps  must 
be  taken  by  the  Army  to  reach  its  near-term  objectives  and, 
eventually,  its  long-term  capability  objectives: 

.  refinement  of  procedures  for  a  life-cycle 
control  system  to  ensure  comprehensive 
reporting  of: 

.  basic  management  requirements; 

.  systems  designed  to  meet  these 
requirements ; 

.  progress  during  the  development 
of  these  systems  throughout  the 
Army  ; 

.  development  of  a  resource  monitoring  system 
(in  conjunction  with  the  Controller  of  the 
Army)  to  measure  costs,  manpower,  machine 
time  (computer  time) ,  and  other  r  rce 
expenditures  during  the  development  and  opera¬ 
tions  of  systems;  and 
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.  development  of  a  comprehensive  systems  man¬ 
agement  guideline  for  MISD's  use  in  applying 
weapons  systems  acquisition  concepts  to  the 
development  of  information  systems  throughout 
the  Army. 

These  objectives  are  discussed  more  fully  in  the  following 
paragraphs . 

Procedures  for  Life-Cycle  Control  System 

As  a  result  of  its  study,  PML  recognized  that  the 
primary  causes  for  system  deficiencies,  both  in  terms  of 
costs  and  of  meeting  performance  objectives,  are  the 
failure  to  adequately  define  system  requirements  and  the 
failure  to  follow  a  logical  progression  of  steps  through¬ 
out  the  system  development  process.  In  too  many  cases, 
system  development  and  programming  begin  immediately 
after  concept  development,  without  an  adequate  system 
design  and  project  plan. 

Peat,  Marwick,  Livingston  &  Co.,  in  conjunction  with 
MISD,  has  identified  a  series  of  phases  (i.e.,  the  life 
cycle)  through  which  a  system  must  pass  if  the  development 
effort  is  to  bo  efficient  and  successful.  In  addition, 
report  formats  have  been  defined  to  indicate  the  comple¬ 
tion  of  these  steps  and  to  provide  MISD  with  an  adequate 
data  base  for  reviewing  the  overall  status  of  system 
development  in  the  Army.  These  concepts  are  outlined 
in  Section  III  of  this  report.  An  initial  set  of  procedures 
for  improving  the  current  information  system  environment 
is  contained  in  the  draft  AR  18-XX  in  Appendix  D.  These 
procedures  may  be  enhanced  and  extended  to  incorporate  the 
total  life-cycle  management  concept. 

Resource  Monitoring  System 

To  ensure  effective  use  of  the  scarce  Army  resources 
available  for  information  systems,  Peat,  Marwick,  Livingston 
&  Co.  has  identified  a  resource  monitoring  system  that  will 
report  planned  and  actual  expenditures  (in  terms  of  dollars, 
manpower,  and  other  critical  resources)  for  system  develop¬ 
ment  projects.  Additional  information  requirements  were 
identified  for  the  collection  of  data  on  manpower  and 
machine  time  and  dollar  costs  for  the  operation  of  indi¬ 
vidual  systems.  Although  the  latter  data  may  be  difficult 
to  obtain,  it  is  extremely  important: 
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.  to  provide  a  basis  for  improved  estimation 
of  operation  costs  during  the  development 
phase;  and 

.  to  permit  better  forecasting  of  workload 
requirements  for  data  processing  installa¬ 
tions  (DPIs)  and  for  specific  computer  con¬ 
figurations. 

These  requirements  for  the  collection  of  data  as  individual 
systems  have  been  forwarded  to  COA  by  MISD  and  are  presently 
under  review.  There  appears  to  be  general  agreement  on 
objectives,  and  alternative  procedures  for  actual  collection 
of  data  are  being  analyzed. 

Systems  Management  Guideline 

Although  the  above  reports  and  data  collection  pro¬ 
cedures  provide  MISD  and  the  HQDA  Staff  with  a  good,  top- 
level  management  tool,  they  can  be  effectively  responded 
to  only  if  corresponding  system  manager  cnt  techniques  are 
applied  by  those  actually  charged  with  the  responsibility 
of  developing  information  systems.  These  techniques  are 
currently  being  used  in  the  weapons  systems  acquisition 
process  with  good  results,  and  are  equally  applicable  to 
the  tasks  of  system  development. 

The  system  management  approach  includes  the  develop¬ 
ment  of  a  complete  project  reporting  system,  correlated  to 
the  major  end  products  of  the  effort;  the  application  of 
configuration  management  techniques,  including  the  defini¬ 
tion  of  baseline  specifications  that  establish  the  critical 
measures  of  system  performance;  and  the  utilization  of  an 
effective  change  control  procedure  to  ensure  agreement  by 
those  affected,  i.e.,  from  the  programmer  to  the  ultimate 
management  user. 

Tasks  and  Products 

Accomplishment  of  the  above  three  objectives  could  be 
divided  into  two  major  tasks; 


.  assistance  in  testing  and  implementing  the 
proposed  reporting  and  data  collection  pro¬ 
cedures;  and 

.  development  of  a  supporting  "Systems  Manage¬ 
ment  Guide"  lor  use  in  managing  the  develop¬ 
ment  of  management  information  systems,  uti¬ 
lizing  the  life-cycle  approach. 
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Task  1;  Assistance  in  Implementation 

The  task  of  assisting  the  Management  Information 
Systems  Directorate  in  implementing  the  above  recommenda¬ 
tions  would  consist  of  a  variety  of  support  efforts.  These 
efforts  are  described  below. 

Assist  in  Implementing  Procedures .  Providing  the  Army 
with  assistance  in  implementing  the  life-cycle  control 
system  procedures  would  be  the  primary  purpose  of  this 
task.  This  effort  would  include: 

.  assisting  MISD  in  testing  the  draft  procedures; 

.  explaining  the  procedures  to  HQDA  staff  and 
field  personnel; 

.  assisting  MISD  in  accepting  and  evaluating 
initial  submissions;  and 

.  revising  procedures  if  operating  difficulties 
arise. 

Refine  Resource  Monitoring  Procedures.  The  second 
important  effort  would  be  to  assist  MISD  in  refining 
resource  monitoring  procedures  for  use  in  management  in¬ 
formation  system  development  and  operation.  This  effort 
would  include: 

.  analyzing  and  reviewing  the  proposed  data 
collection  system; 

.  identifying  detailed  changes  required  in  the 
accounting  system  and  the  other  reporting 
systems ; 


.  developing  specific  formats  for  reports  to 
MISD  and  the  HQDA  staff;  and 

.  assisting  MISD  to  integrate  this  information 
with  that  collected  through  the  life-cycle 
control  system  procedures. 

Review  Regulatory  Structure.  This  effort  would  call 
for  assisting  MISD  in  a  comprehensive  review  of  the  entire 
series  of  regulations  governing  management  information 
systems.  This  review  should  result  in  recommendations 
for  changes  in  existing  regulations  to  permit  more  efficient 
and  effective  management. 
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Develop  Internal  MISD  Procedures.  The  development  of 
internal  MISD  procedures  would  build  on  the  MISD  procedures 
checklists  developed  to  guide  in  the  review  of  the  documents 
prescribed  in  the  life-cycle  control  system.  As  data 
become  available  through  the  life-cycle  control  system  and 
the  resource  monitoring  system,  MISD  would  require  some 
level  of  automated  support  to  effectively  accept  and  work 
with  the  information.  This  effort  could  be  accomplished 
through  a  simple,  but  flexible  file  maintenance  and  report¬ 
ing  system  to  permit  MISD  to  maintain  current  plans  and 
status  information  on  major  systems  and  to  report  this 
information  in  a  variety  of  ways. 

Tas^  2:  Development  of  Systems  Management 

Gu  ^eline 

For  the  reporting  procedures  of  the  life-cycle  control 
system  to  be  effective,  they  must  summarize  a  more  detailed 
and  comprehensive  management  system  to  assist  those 
directly  responsible  for  managing  and  developing  new  infor¬ 
mation  systems.  It  is  recognized  that  the  development  of 
a  large  information  system,  like  the  development  of  a  large 
hardware  system,  must  be  carefully  planned  and  managed  if 
the  most  effective  result  is  to  be  obtained  within  time  and 
resource  constraints. 

The  purpose  of  this  task  would  be  to  develop  a 
detailed  guide  for  the  application  of  the  life-cycle  con¬ 
cept  of  system  management  to  the  development  of  MISs.  It 
is  assumed  that  the  guide  would  not  be  a  compulsory  set 
of  regulations,  but  would  explain  the  basic  concepts  of 
life-cycle  systems  management  as  applied  to  information 
system  development.  It  is  further  assumed  that  the  guide 
would  illustrate  these  concepts  with  usable  formats  and 
procedures.  Although  the  final  contents  of  the  guide 
would  be  developed  during  the  propose'  effort,  it  is 
probable  that  the  topics  discussed  in  the  following  para¬ 
graphs  would  be  covered. 

Organization.  The  organization  section  of  the  guide 
would  deal  with  the  principles  of  effective  project  organi¬ 
zation  and  the  relationship  of  pr.oject  organization  to  the 
end  product-  or  objective*-  of  the  effort  and  to  cost  and 
resource  control.  The  section  would  include  recommended 
responsibi  1  j  ti  er  frr  the  projev*  manager  and  his  principal 
technical  sujrporti -.g  managers,  a„  ‘-'ell  as  an  outline  of 
the  role  of  the  U'j&A  starf  an  "elated  field  organizations. 
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Project  Planning.  The  project  planning  section  would 
deal  with  methods  of  establishing  a  realistic  project  plan 
estimating  cost,  manpower,  and  other  critical  resources; 
developing  and  using  a  work  breakdown  structure  for  the 
project;  establishing  baseline  performance  specifications 
for  the  system;  and  identifying  funding  sources  and  con¬ 
tractual,  facility,  equipment,  and  other  support  require¬ 
ments. 

Progress  Reporting.  The  progress  reporting  section 
would  deal  with  the  development  of  an  effective  progress 
monitoring  system.  The  system  would  be  established  to 
continuously  track  the  status  of  critical  end  items  in 
terms  of  time,  cost,  and  performance,  and  to  identify 
potential  problems  prior  to  their  occurrence. 

Change  Control.  The  change  control  section  would 
deal  with  methods  of  identifying  changes  to  the  system, 
of  assessing  the  impact  of  these  changes  in  terms  of  time, 
cost,  and  performance,  and  of  developing  a  review  and 
approval  prejess  to  ensure  communication  of  all  changes 
to  those  affected  with  a  minimum  of  time  and  administra¬ 
tive  workload. 

Documentation.  The  documentation  section  would 
deal  with  efficient  and  effective  means  of  system  documen¬ 
tation  at  all  levels,  from  overall  design  through  detailed 
program  documentation  and  operating  procedures 

Project  Schedule 

Peat,  Marwick,  Livingston  i>  Co.  anticipates  that  the 
two  major  task  areas  involved  in  che  implementation  am? 
testing  of  the  life-cycle  control  system  and  the  develop¬ 
ment  of  a  supporting  systems  management  guideline  to 
achieve  the  three  near-term  objectives  would  be  conducted 
concurrently  over  a  12-month  period. 
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APPENDIX  A 


REQUI REMENT  DEFINITION  DOCUMENT  FORMATS 


This  appendix  contains  descriptions  of  documents  sub¬ 
mitted  to  MISD  during  the  requirement  definition  segment 
of  the  system  life  cycle.  An  attempt  has  been  made  to  ap¬ 
proximate  the  format  of  the  actual  documents,  as  well  as 
to  include  descriptions  of  the  information  required  for 
each.  The  documents  described  are: 

.  Guidance  and  Reporting  System  Requirement  (RSR) 

.  Guidance  and  Reporting  System  Specification  (RSS) 

.  Operating  Information  System  Requirement  (OISR) 

.  Operating  Information  System  Development  Plan  (OISDP) 

.  Operating  Information  System  Specification  (OISS) 

.  Application  Specification 
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GUIDANCE  AND  REPORTING  SYSTEM  REQUIREMENT  (RSR) 


Purpose  of  RSR 

a.  This  agency  has  a  requirement  for  a  Guidance  and 
Reporting  System  to  provide  information  services 
at  HQDA  in  the  following  functional  areas: 

(List  areas,  i.e..  Finance,  Logistics,  etc.) 


b.  The  proposed  G&R  Sys:  m  will  also  satisfy,  in  full 
or  in  part,  inforr.atici  requirements  in  the  above 
functional  areas  for  th«-'  following  organizations  or 
agencies : 

_ (Name  agency  or  command,  designating _ 

organizational  level) 


c.  The  system  will  also  provide  the  following: 


Background 


a.  Reference  is  made  to  the  following  directives: 


b.  General :  (Describe  background  and  events  leading 
to  recognition  of  the  information  requirement. 

State  why  the  requirement  exists,  relating  it  to 
organization  missions  and  functions.  If  the  re¬ 
quirement  is  currently  supported  or  satisfied  in 
full  or  in  part  by  an  existing  information  system, 
describe  changes  in  environment  or  inadequacies  of 
current  system  that  make  it  unsatisfactory  for  con¬ 
tinued  use . ) 


System  Description 


a.  Objective  cf  the  System:  (State  objective  of 
system  or  of  system  improvement.  That  is,  state 
the  products  and  services  of  the  system  in  terms 
of  performance;  e.g.,  the  system  will  provide 
civilian  pay  expenditure  information  at  HQDA  prior 
to  5th  working  day  of  the  following  month.  In¬ 
clude  the  frequency  of  requiring  the  products  and 
services . ) 

b .  Functions  To  Be  Supported  by  the  Proposed  System : 
(State  the  uses  of  the  system  products  in  terms  of 
functions  supported,  such  as  monthly  review  of  ex¬ 
penditure  for  civilian  pay.) 

c.  Scope:  (State  information  functions  encompassed 
at  any  processing  level,  e.g.,  all  civilian  man¬ 
power  management  functions  except  daily  time  and 
attendance  records  for  pay  purposes.  State  the 
extent  of  changes  to  present  procedures  arc?  in¬ 
formation  requirements. 


d.  Supportinq  Organization 


Elements 


The  following  Army  organizations  will  be 
required  to  perform  the  designated  functions 
within  this  system: 


Data 
GLs .  6 
Becd ' ing 


Manual 
Drep.  oi 
Reports 


Automated 
Prep,  of 
I  Reports 


Receipt , 
Use  of 
Reports 


(2) 


Data  Processing  Installations 


It  is  anticipated  that  data  processing  in 
support  of  this  system  will  be  performed  at 
the  following  data  processing  installations 
(DPI's)  in  support  of  the  following  organi¬ 
zations  : 

DPI 1 s  Organizations 


Information  and  Data 


(1 )  Information  and  Data  Elements 

The  following  data  elements  or  data  element 
groups  (e.g.,  civilian  employee  identifica¬ 
tion,  hours  worked  by  week,  absences,  and 
leave)  will  be  observed,  recorded,  processed 
and  reported  within  this  system: 


(2)  The  basic  sources  of  data  entering  this 
system  are: 

Data  Element  or  Group  Source 


(If,  within  this  G&R  System,  data  is  not 
gathered  at  source  but  is  obtained  from  other 
information  systems,  describe  method  of  oper¬ 
ation  of  other  system  up  to  the  point  at 
whi~h  data  or  information  enters  proposed 
G4R  System. ) 

(3)  Data  Flow:  (Include  a  flow  chart,  using 

symbols  per  AR  18-7,  that  illustrates  flow 
of  data  from  source,  through  reporting  or¬ 
ganization,  to  final  information  user;  show 
interfaces  with  other  GfcR  Systems.  State 
briefly  the  processing  to  be  accomplished  by 
DPI's  and  tne  communication  media  to  be  used. 


4. 


Resource  Requirements  by  Fiscal  Year:  (Prepare  esti¬ 
mates  of  total  resource  expenditures  for  development 
and  operation  of  the  system  by  fiscal  year.  Identify 
specific  tasks  that  will  involve  significant  resource 
expenditures ,  e.g.,  new  ADPE  purchases,  large  new 
development  efforts,  major  modifications  to  existing 
operating  systems.  State  how  the  system  will  be 
financed  during  its  life  cycle,  and,  if  system  devel¬ 
opment  is  funded,  note  source  of  funds.  State  re¬ 
quirements  for  Program  Change  Proposals.) 

a.  Development 

Indicate  resource  expenditures  for  system  devel¬ 
opment  as  follows: 


Current 

FY 

FY+1 

FY+2 

FY+3 

FY+4 

FY+5 

COST  DATA* 

Government 

Personnel 

Services 

Contractual 

Services 

ADPE 

Personnel 

Other 

Capital 

Investment 

ADPE 

Other 

TOTAL 

MANPOWER 

DATA** 

Military 

Civilian 

TOTAL 

*In  thousands 
**In  man-years 

of  dollars 

A. 5 


b.  Operation 

Indicate  resource  expenditures  for  system  opera¬ 
tion  as  follows: 


COST  DATA* 

Government 

Personnel 

Services 

Contractual 

Services 

ADPE 

Personnel 

Capital 

Investment 

ADPE 

Other 

TOTAL 

MANPOWER 

DATA** 

Military 

Civilian 

TOTAL 

Current 

FY 

FY+1 

FY+2 

FY+3 

FY+4 

FY+5 

_ 

*In  thousands  of  dollars 
**In  man-years 

Other  Comments 


GUIDANCE  AND  REPORTING  SYSTEM  SPECIFICATION  (RSS) 


1.  Identification  and  Purpose  of  RSS 
a.  Identification 

( 1 )  System  title;  _ 

(2)  System  number  (assigned  by  MISD) : 

(3)  Agency  submitting  RSS;  _ 

(4)  Reference  to  original  RSR: 

(a)  Date  and  proposed  title:  _ 


(b)  Agency  submitting  RSR: 


(5)  Reference  to  directives: 


b.  Purpose 

(1)  The  proposed  G&R  System  will  support  HQDA 
management  information  requirements  in  the 
following  functional  areas: 

tLlst  areas,  i.e.,  Finance,  Logistics) 


(2)  The  proposed  GfcR  System  will  support,  in 
full  or  in  part,  information  requirements 
in  the  above  functional  areas  for  the  fol¬ 
lowing  agencies  or  organizations: 

(Name  agency  or  organisation) _ 
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(3)  The  system  will  also  provide  the  following 
services : 


2.  Revised  RSR  Items:  (Entries  should  be  made  in  this 

section  only  if  Items  are  changed  from  RSR  entries.) 

a.  Objective  of  System:  (State  objective  of  system 
or  of  system  improvement.  That  is,  state  the 
products  and  services  of  the  system  in  terms  of 
performance;  e.g.,  the  system  will  provide  civil¬ 
ian  pay  expenditure  information  at  HQDA  prior  to 
5th  working  day  of  following  month.  Include  the 
frequency  of  requiring  the  products  and  services.) 

b.  Functions  To  Be  Supported  by  the  Proposed  System: 
(State  the  uses  of  the  system  products  in  terms 
of  functions  supported,  such  as  monthly  review 

of  expenditure  for  civilian  pay.) 

c.  Scope :  (State  information  functions  encompassed 
at  any  processing  level,  e.g.,  a1 1  civilian  man¬ 
power  management  functions  except  daily  time  and 
attendance  records  for  pay  purposes. 

d .  Supporting  Organization 
(1 )  Army  Elements 

The  following  Army  organizations  will  be 
required  to  perform  the  designated  functions 
within  this  system: 
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(2)  Data  Processing  Installations 

It  is  anticipated  that  data  processing  in 
support  of  this  system  will  be  performed  at 
the  following  data  processing  installations 
(DPI's)  in  support  of  the  following  organi¬ 
zations  : 

DPI's  Organizations 


e.  Information  and  Data 

(1 )  Information  and  Data  Elements 

The  following  data  elements  or  data  element 
groups  (e.g.,  civilian  employee  identifica¬ 
tion,  hours  worked  by  week,  absences,  and 
leave)  will  be  observed,  recorded,  processed 
and  reported  within  this  system: 


(2)  The  basic  sources  of  data  entering  this  system 
are: 

Data  Element  or  Group  Source 


(If,  within  this  GAR  System,  data  is  not 
gathered  at  source  but  is  obtained  from  other 
information  systems,  describe  method  of  oper¬ 
ation  of  other  system  up  to  the  point  at 
which  data  or  information  enters  proposed 
G4R  System,) 

(3)  Data  Flow:  (Include  a  flow  chart,  using 
symbols  per  AR  18-7,  that  illustrates  flow 
of  data  from  source,  through  reporting  or¬ 
gan:  taMon,  to  final  information  user:  show 
ir’  s  with  other  GAR  Systems.  State 

b*  he  processing  to  be  accomplished  by 

DU  .  the  communication  med.r.a  ■  c  be  used.) 
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3 .  System  Specification 

a.  System  Overview:  (Provide  a  flow  chart  and  narra¬ 
tive  for  Army  organizations  and  data  flow  with 
DPI's  identified  by  number  for  each  Army  organ¬ 
ization.  ) 

b.  Source  Data  Groups  or  Elements  Specifications; 
(Indicate  the  source  ot  data.  If  data  is  not 
collected  at  operational  source,  show  how  data 
is  obtained  from  another  information  system  (s) 
and  trace  to  source.  Indicate  method  of  ob¬ 
serving  and  reporting  data  showing  source  docu¬ 
ment  format  and  general  instructions  for  prep¬ 
aration.  ) 

c .  Processing 

For  each  processing  level,  indicate  the  following: 
(1)  Master  File  Descriptions  (for  each  OIS) 

(a)  Content :  (List  information  items 
contained . ) 

(b)  Record  Format:  (Show  sample  formats.) 

(c)  Sequence  (medium) ,  etc.:  _ 


(2)  Input/Output  and  Report  Specifications 

This  should  indicate,  for  each  OIS,  speci¬ 
fications  of  tape  or  card  files  transmitted 
between  processing  levels,  as  well  as  any 
printed  reports. 

(a)  Content :  (List  information  items 
contained , ) 

(b)  Record  Format:  (Show  sample  formats 
in  accordance  with  AR  18-7.) 

(c)  Sequence : 


/:  ,/ 


;t  tMc:  % 
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(3)  Processing  Required:  (Include  a  flow  ''hart 
and  narrative,  plus  information  on  data 
controls,  e.g.,  records  counts,  hash  totals, 
etc.,  and  backup  files  required.) 

4.  Development 

State  the  approach  for  the  accomplishment  of  the  re¬ 
quirement,  in  terms  of: 

a.  Major  Tasks  and  End  Products:  (List.) 

b.  Financial  Support  Base:  (Identify.) 

c.  Organization  and  Responsibilities:  (Identify.) 

d.  Schedule  of  Accomplishment:  (Prepare  a  Gantt 

cKartTJ - - 

5.  Other  Comments: 
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OPERATING  INFORMATION  SYSTEM  REQUIREMENT  (OISR) 


1.  Identification  and  Purpose 


a.  Purpose 


This  command/agency  has  a  requirement  to  develop 
an  Operating  Information  System  to  support: 


(1) 


the  following  Guidance  and  Reporting  Systems 


(Specify  the  proponent  agency  and  RSS 
by  title  and  reference) 


(2) 


the  following  other 


information 


requirements 


b.  Identif lcation 

(1)  MA  Proposed:  _ 

(2)  RDA  Proposed:  _ 

(3 )  Project  Manager  Proposed: 

2 .  Background  and  System  Concept 


a .  Background 

(1)  Applicable  Directives: 


(2)  Peroral :  (Describe  events  leading  to 
recognition  of  need  to  develop  OIS.! 

b.  System  Concept 

'U  Objective  of  System:  (State  objective  of 
system  or  ot  the  improvement  project  in 
performance  terr..,  e.g..  reduce  requisition 
turnaround  time  to  less  than  four  hours,  if 
possible . ) 
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(2) 


Scope;  (State  information  functions  encom¬ 
passed  at  any  processing  level,  e.g.,  all 
civilian  manpower  management  functions  except 
daily  time  and  attendance  records  for  pay 
purposes.  If  a  multi-functional  system,  de- 
cribe  all  information  functions  by  functional 
area. ) 

c.  Data  Processing  Installations:  (List  data  proces- 
sing  installations  that  will  operate  system.) 

Resource  Requirements 
a.  Development 

Indicate  resource  expenditures  for  system  devel¬ 
opment  as  follows: 


COST  DATA* 

Government 

Personnel 

Services 

Contractual 

Services 

ADPE 

Personnel 

Other 

Capital 

Investment 

ADPE 

Other 

TOTAL 

MANPOWER 

DATA** 

Military 

Civilian 

TOTAL 

Current 

FY 

FY+1 

FY+2 

FY+3 

FY+4 

' 

FY+5 

_ 

_  .  .  _ 

*In  thousands  of  dollars 
**In  man-years 
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b.  Operation 


Indicate  resource  expenditures  for  system  opera¬ 
tion  as  follows: 


Current 

FY 

FY+1 

FY+2 

FY+3 

FY+4 

FY+5 
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OPERATING  INFORMATION  SYSTEM  DEVELOPMENT  PLAN  (OISDP) 


1 .  Purpose  of  OISDP 

This  agency  has  a  requirement  to  develop  the  Operating 
Information  System (s)  identified  in  2.  below.  This 
proposal  details  the  tasks  that  must  be  accomplished 
to  develop  these  systems ,  schedules  for  accomplishing 
the  tasks,  and  supporting  management  data.  (One  OISDP 
is  to  be  submitted  for  each  set  of  Operating  Informa¬ 
tion  Systems  for  which  a  common  development/improvement 
effort  is  intended.) 


2.  Identification 


a.  Title  and  Number  of  OIS:  (Each  OIS  has  a  title 
that  need  not  be  unique .  Numbers  are  assigned 
by  MISD.) 

b.  Organization  Submitting  OISDP  (originator) :  _ 


c .  Monitoring  Agency:  _ 

d.  Guidance  and  Reporting  System  Supported  by  OIS: 
(List  the  name(s)  and  number(s)  of  the  Gfc&S  for 
which  the  systems  are  components.) 

e.  References ; 

(List  preceding  OISR,  RSS) _ 


3.  Purposes  of  OIS;  (or  collective  purposes  for  a  set  of 
systems. ) 


a.  The  proposed  OIS  will  provide  information  services 
to  the  referenced  G4RS  in  the  following  functional 
ways : 

(List  the  major  functional  services  to  be  pro¬ 
vided  for  the  referenced  GfcRS  by  one  or  more 
OIS;  e.q.,  collect  and  summarize  xxxx  data 
and  produce  xxxx  reports,  etc.) 
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b.  The  proposed  OIS  will  provide  the  following  ad¬ 
ditional  services  for  other  G&RS: 


4.  Revisions  of  Preceding  RSS  or  OISR:  (State  information 
updating  the  preceding  baseline  documents,  relating 
items  to  the  formats  of  those  documents.) 

5 .  Plans  for  Developing  OIS 

A  development  plan  must  be  included  for  each  OIS, 
indicating  the  following : 

a.  Work  Breakdown  Structure  and  Networks;  (List  tasks 
and  milestones  to  be  accomplished,  specifying  end 
products.  Show  task  and  product  accomplishment 
relationships  via  PERT  chart  to  permit  management 
control  over  progress.) 

b.  Organization  and  Responsibilities:  (State  which 
organizations  are  responsible  for  accomplishing 
which  tasks  and  show  overall  organization  structure 
including  MA  and  ARA.  Specify  System  Manager.) 

c.  Schedules :  (Show  schedules  for  accomplishment  of 
tasks . ) 

d.  Progress  Reporting;  (Identify  periodic  reports  to 
be  submitted  showing  status  of  accomplishment, 
achievement  of  milestones,  and  expenditure  of  re¬ 
sources,  together  with  frequency  of  reporting.) 
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6 .  Resource  Requirements 
a.  Development 

Indicate  resource  expenditures  for  system  devel¬ 
opment  as  follows: 


- 

COST  DATA* 

Government 

Personnel 

Services 

Contractual 

Services 

ADPE 

Personnel 

Other 

Capital 

Investment 

ADPE 

Other 

TOTAL 

MANPOWER 

DATA** 

Military 

Civilian 

TOTAL 

Current 

FY 

FY+1 

FY+2 

FY+3 

FY+4 

I 

FY+5 

j 

l 

i 

*In  thousands  of  dollars  i 

**In  man-years 
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Other  Comments: 


OPERATING  INFORMATION  SYSTEM  SPECIFICATION  (OISS) 


1.  Identification 

a.  Operating  Information  System  (OIS)  Title; 


b.  OIS  Number  (assigned  by  MISD) :  _ 

c.  Associated  Guidance  and  Reporting  System; 


d.  References  (as  required)  : 

(Preceding  RSS  or  OISR) _ 

(Operating  System  Directive (s) ) _ 

(OISDP) _ 

2 .  Purpose 

The  purposes  of  the  technical  specification  and  of  the 
subject  OIS  are: 


3,  Performance  Requirements:  (State  assumptions,  con¬ 
straints,  details  lor  OIS  performance  service,  and 
functional  goals.  Relate  with  RSS  and  GfcRS.  Include 
date  from  RSR.  Quantify  where  possible.) 

4.  Products 


Describe  what  the  system  as  a  whole  is  to  produce  and 
relate  this  to  performance  requirements.  List  major 
outputs  of  system,  including: 

a.  Reports  (periodic  and  unscheduled):  _ 
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c.  Other  Services  Provided  (for  instance,  handling  of 
ad  hoc  queries,  optional  features,  significant 
functions  such  as  analyses,  decision  criteria): 


b.  Inputs 

a.  Data :  (Include  content,  format,  limits,  accuracy, 
precision ,  media,  sources,  methods  of  collection, 
and  mechanization.) 

b.  Files :  (Include  content,  format,  structure,  keys, 
and  media.) 

c.  Media:  (Include  communications,  volumes,  and  timing.) 

6.  Data  Flow:  (Include  flow  charts  that  indicate  the  flow 
of  information  and  processing  logic  from  input  to  out¬ 
put  for  each  application  and  for  the  system  as  a  whole.) 

7.  Application  Description:  (List,  for  each  application  that 
is  to  be  developed  as  a  work  package,  the  equipment,  lan¬ 
guage,  organization,  interfacing  considerations,  input/ 
output  lists,  intermediate  results,  files,  operating  pro¬ 
cedures,  quality  controls,  and  error  procedures.) 

8.  Documentation :  (Describe  the  system  documentation  to  be 
provided,  including  outlines  of  the  contents  of  each 
document . ) 

9.  Communications :  (State  the  communications  methods,  media, 
volumes,  and  systems  that  are  to  be  employed.  Include 
interface  characteristics  for  exchanging  information  with 
other  systems.) 

Testing :  (Present  preliminary  design  for  testing,  valida¬ 

tion,  acceptance,  and  implementation  of  system.) 

11.  Design  Requirements:  (Include  data  on  languages,  equip¬ 
ment  constraints,  program  modularity,  etc.) 
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APPLICATION  SPECIFICATION 


An  Application  Specification  is  to  be  developed  for 
each  OISS  application  description.  This  specification  is 
supported  by  other,  separately  promulgated  publications  that 
prescribe  Army  policies,  standards,  and  methodology  in  the 
areas  of  analysis,  design,  and  programming.  These  publica- 
tions  reduce  the  continual  redevelopment  of  these  conven¬ 
tions  and  gain  a  common  discipline  for  training. 

Details  for  information  needed  in  the  technical 
specifications  for  applications  have  not  been  included  in 
this  report.  The  descriptions,  standards,  and  conventions 
that  are  needed  to  define  these  specifications  place  them 
beyond  the  scope  of  the  report.  Briefly,  however,  the 
categories  of  information  listed  below  must  be  included. 


1.  Identification;  (Describe  contextual  and  background 
material ,  including  security  factors.) 

2.  User  Requirements;  (Define  the  outputs  of  the  system  in 
terms  of  objective  or  purpose  for  the  system,  products 
(e.g.,  reports),  services  rendered  (e.g.,  file  mainte¬ 
nance),  media  dissemination  and  form,  and,  especially, 
performance  specifications.) 

3.  Interval  System  and  Programming  Details;  (Represent  the 
logic  of  tne  information  processing  that  transforms  in¬ 
puts  into  outputs  for  each  program,  including  relation¬ 
ships  between  components,  the  sequence  of  events  (through 
narratives  and  flow  charts),  decision  tables,  and  other 
facts  needed  by  the  programming  staff  and  the  (future) 
program  maintenance  staff  such  as  interfaces  between  sub¬ 
programs  and  timing  estimates.) 

4.  System  Inputs;  (Describe  the  information  entered  into 
tne  system,  including  the  media,  form,  distribution, 
volumes  (average,  peaks,  lows),  and  handling  procedures.) 

5.  Data  Elements:  (Include  definition,  content,  format, 
limits,  accuracy,  precision,  media,  forms,  and  sources.) 

6.  Quality  Controls:  (Define  needs  and  procedure**  for 
assuring  data  quality  through  the  system,  including, 
for  instance,  audit  trails.) 
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7.  System  Configuration;  (Describe  equipment  (installed/ 
required) ,  information  flows  (including  communications 
interfaces) ,  storage  allocation,  program  organization, 
file  structure,  and  supervisory  (executive)  systems, 
including  facilities  and  communications  requirements.) 

8.  Error  Procedures:  (Include  descriptions  of  controls  and 
procedures  within  programs,  communications,  and  handling 
procedures.  Describe,  within  each  program's  flow  chart, 
how  data  quality  will  be  assured,  documentation,  and 
recovery  procedures. 

9 .  File  and  Table  Descriptions 

0.  Testing  Considerations:  (Describe  structure  of  test  in- 
cTu3Tng  procedural  aspects,  integration  of  components, 
and  responsibilities  for  test  development.) 
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APPENDIX  B 


PROJECT  MANAGEMENT  REPORT  FORMATS 


This  appendix  contains  sample  forms  for  the  Project 
Management  Reporting  System  outlined  in  Section  V.  The 
reports  described  are  the  following.  Figure  B.l  shows  the 
distribution  of  all  reports. 

.  The  Project  Summary  Report  is  a  monthly  summary 
of  the  status  of  major  information  system  projects 
and  studies.  This  report  contains  a  tabular 
listing  of  status  of  each  project/study  cost 
and  schedule,  with  a  short  narrative.  It  is 
intended  for  RDA's,  monitoring  agencies,  MISD, 
and  staff  agencies. 

.  The  Project  Management  Report  is  a  monthly  status 
report.  One  report  Is  prepared  for  each  system 
project  or  study  that  is  included  in  the  Project 
Summary  Report.  The  Project  Management  Report 
includes  a  project/study  description,  cost  and 
schedule  status,  and  a  problem  analysis.  This 
report  is  designed  for  RDA's,  monitoring  agencies, 
project  managers,  and  project  engineers.  MISD 
and  Army  staff  agencies  receive  individual  Project 
Management  Reports  on  an  exception  basis  or  on 
request. 

.  Lower  Level  Project  Management  Reports  provide 
data  on  the  monthly  status  of  a  project/study  in 
a  form  identical  to  that  of  the  Project  Management 
Report,  but  include  more  detailed  information  for 
separate  phases  or  parts  of  individual  projects. 

These  reports  offer  flexibility  in  reporting  at 
different  levels  of  detail,  depending  on  the  size 
and  complexity  of  the  project  and  the  division  of 
management  responsibilities.  The  Lower  Level  Project 
Management  Reports  are  intended  for  project  man¬ 
agers  and  project  engineers;  RDA's  and  monitoring 
agencies  receive  the  reports  on  request.  Because 
the  actual  composition  of  the  reports  varies  with 
the  information  requested,  this  report  is  not 
described  in  greater  detail  in  this  appendix. 
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MONTHLY 

NISO 

TOTAL 

REPORT 

REQUEST/ 

EXCEPTION* 

STAFF 

AGENCIES 

total 

REPORT 

MONITORING 

AGENCIES 

PARTIAL  REPORT 
PER 

RESPONSIBILITY 

ALL 

APPROPRIATE 

PROJECTS 

VMEN 

REQUESTED 

RESPONSIBLE 

DEVEL0PMEN1 

AGENCIES 

PARTIAL  REPORT 

•HER 

REQUESTED 

ALL 

APPROPRIATE 

PROJECTS2 

all 

APPROPRIATE 

PROJECTS 

PROJECT 

MANAGERS/ 

PROJECT 

ENGINEERS 

PARTIAL  RE?0RT 

tHER 

REOvESTEO 

ALL 

APP!3PRiA?I 

PROJECTS 

ALL 

APPROPRIATE 

pROjEC’S 

*  If QUfS'/t ADEPTS  %E  M'.L  SI  I'Vi  Bi'E?  V*E*  AEQJEST 

t*ct»t.o%  *i,:$  f  a.***‘%  t**;{  > 

are 


:a  •:%  a* 

;pa:e 


l 

a.,  i»ich-i!|  »'*•:«'  m:ih5o  ton  all  pnojic-s  •» i%: «  ojals 

*{3»:«s  m-ri 


FIGURE  *f  i- REPORT  DISTRIBUTION  MATRIX 


B.2 


PROJECT  SUMMARY  REPORT 


A  sample  Project  Summary  Report  is  shown  in  Figure  B.2. 
This  sample  illustrates  that,  for  each  project,  one  line  of 
tabular  status  data,  plus  two  lines  of  narrative,  is  pro¬ 
vided.  The  various  projects  can  be  listed  in  any  order, 
such  as  by  responsible  agency,  by  decreasing  dollar  si2e, 
etc.,  to  improve  readability  of  the  report.  The  column  and 
line  headings  of  the  report  are  as  follows: 

.  PROJECT:  identifies  a  project  by  name  and  project 
number; 

.  ORGN  RES:  identifies  the  organization  responsible 
£or  the  project; 

*  CONT.  TYPE:  identifies  the  type  of  contract (s)  that 
applies  to  a  project.  An  MF"  indicates  a  firm  fixed 
price  contract,  "R"  indicates  a  cost  reimbursable 
contract,  and  an  "M"  indicates  combination  of  a  firm 
fixed  price  and  cost  reimbursable  contract.  An  "A" 
indicates  that  the  project  is  an  Army  effort  having 
no  contractual  assistance; 

.  PROJECT  COST  STATUS  -  TO  DATE:  presents  project  cost 
status  in  terms  oi: 

.  ACTUAL :  shows  the  cumulative  actual  costs 
incurred  to  date  by  the  project  office; 

.  PLANKED :  shows  the  cumulative  planned  costs 
that  were  to  be  incurred  to  '’ate  by  the  proj¬ 
ect  office.  This  figure  serves  as  the  basis 
for  comparing  actual  and  planned  costs; 

.  VAR.  $ :  shows  the  amount  ACTUAL  column  less 
the  amount  PLANNED  column,  in  dollars; 

.  VAR .  % :  shows  the  VAR.  $  over  the  amount  in 
PLANNED  column  x  100; 

.  PROJECT  COST  STATUS  -  AT  COMPLETION: 

.  LATEST  ESTIMATE;  shows  the  Project  Manager's 
latest  total  project  cost  at  completion  and  is 
based  on  data  from  all  sources; 

.  BUDGET :  shows  the  approved  budget  for  the 
project  and  is  the  basis  for  comparing  LATEST 
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ESTIMATE  and  the  budget; 

.  VAR.  $:  shows  LATEST  ESTIMATE  less  the 
BUDGET; 

•  VAR.  %:  shows  VAR.$  over  the  BUDGET  x  100; 

.  TREND:  shews  the  change  in  LATEST  ESTIMATE 
from  previous  month  to  current  month.  If 
LATEST  ESTIMATE  is  greater  for  the  current 
month,  show  +;  if  the  LATEST  ESTIMATE  is  less 
for  the  current  month,  show  +;  if  there  has 
been  no  change ,  show  0 ; 

PROJECT  FISCAL  STATUS  -  CASH  THIS  FISCAL  YEAR: 

.  FORECAST :  shows  the  Project  Manager's  total 
forecast  cash  payments  to  be  made  in  the  current 
fiscal  year; 

.  BUDGET :  shows  total  budgeted  cash  payments 
to  be  made  in  the  current  fiscal  year  and  is 
the  basis  for  comparing  forecast  and  budget 
costs ; 

•  VAR .  $ :  shows  amount  in  FORECAST  column  minus 
amount  in  BUDGET  column; 

PROJECT  SCHEDULE  STATUS  -  TO  DATE: 

•  MILESTONE  NUMBER:  shows  identifying  number  of 
the  milestone ,  due  for  completion  this  month, 
that  is  being  used  to  reflect  current  schedule 
progress ; 

.  SLACK  WEEKS :  shows  schedule  status  of  the  mile- 
stone  in  terms  of  the  difference  in  expected  or 
actual  completion  from  scheduled  completion  date. 
This  figure  can  be  positive  or  negative  to  indi¬ 
cate  weeks  ahead  or  behind  schedule,  respectively. 
If  a  PERT  network  is  used  on  the  project,  the 
slack  may  be  taken  directly  from  this; 

PRCJECT  SCHEDULE  STATUS  -  AT  COMPLETION: 

.  MILESTONE  NUMBER:  shows  identifying  number  of 
the  milestone  used  to  signify  project  completion; 
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.  SLACK  WEEKS:  shows  schedule  status  of  the  mile¬ 
stone,  as  reflected  in  the  MILESTONE  NUMBER 
column,  in  terms  of  the  difference  between  the 
expected  completion  and  the  scheduled  completion 
date.  This  can  be  positive  or  negative  to  indi¬ 
cate  the  weeks  ahead  or  behind  schedule,  respec¬ 
tively.  This  is  normally  the  slack  of  the 
Critical  Path  if  PERT  is  being  used; 

.  TREND :  shows  change  in  completion  SLACK  WEEKS 
column  from  the  previous  month  to  the  current 
month.  If  expected  completion  date  has  slipped 
from  last  month  to  this  month,  show  if  expected 
completion  date  has  gained,  show  * ;  if  there  has 
been  no  change ,  show  0 . 

The  two  lines  of  narrative  for  each  project  can  be  used 
to  explain  the  meaning  of  the  data  for  cost,  schedule,  or 
fiscal  status  or  to  identify  other  matters  of  particular 
significance . 
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PROJECT  SUMMAR 


PROJECT  COST  STATUS  S(000) 

PROJECT 

TO  DATE 

AT  COMPLE1 

ORGN 

RESP 

CONT. 

TYPE 

ACTUAL 

PLANNED 

VAR.  S 

VAR.  % 

LATEST 

ESTIMATE 

BUDGET 

VAR.  $ 

SUMMARY  REPORT 


REPORT  DATE 


US  K000)  I  PROJECT  FISCAL  STATUS $(000)  I  PROJECT  SCHEDULE  STATUS 


AT  COMPLETION  CASH  THIS  FISCAL  YEAR  TO  DATE  AT  COMPLETION 

BUDGET  VAR.  S  VAR.  %  TREND  FORECAST  BUDGET  VAR.  $  WEEKS  TREND 


FIGURE  B.2 


PROJECT  MANAGEMENT  REPORT 


A  sample  five-part  Project  Management  Report  is  shown  in 
Figure  B.3.  The  various  parts  of  the  report  are  as  follows. 

Part  1;  Project  Description 

Part  1  contains  a  concise  description  of  a  project  for 
use  by  those  report  recipients  who  are  not  actively  involved 
in  day-to-day  management  of  the  project.  Part  1  is  used  as 
a  cover  sheet  for  the  other  parts  of  the  report ,  and,  except 
for  the  date,  changes  only  when  specific  changes  to  the  proj¬ 
ect  plans  (e.g.,  an  increase  in  the  number  of  units  ordered 
or  a  change  in  the  approved  project  funding)  have  been  made. 
The  form  does  not  require  a  detailed  explanation. 

Part  2;  Financial  and  Schedule  Curves 


The  financial  and  schedule  curves  provide  a  graphical 
display  of  financial  information  that  cannot  be  indicated  by 
tabular  data.  This  display  includes  an  assessment  of  trends 
that  provides  management  with  a  pictorial  history  of  previous 
financial  status  and  can  be  used  to  predict  future  results. 
The  following  curves  can  be  plotted,  depending  on  individual 
project  requirements.  Usually  the  information  is  displayed 
in  pairs  of  planned  and  actual  data: 

.  contracts  awarded  -  actual :  the  actual  value  of 
contracts  awarded  to  date; 

•  contracts  awarded  -  planned:  the  planned  costs  for 
those  items  for  whicn  contracts  have  been  awarded 
to  date; 

•  Project  costs  incurred  -  actual:  the  actual  value 
of  project  costs  incurred  to  date; 

•  project  costs  incurred  -  planned:  the  planned  costs 
for  work  that  the  project  has  accomplished  to  date; 

•  Progress  payments  -  actual:  the  actual  value  of 
progress  payments  made  to  the  contractor  to  date; 

•  progress  payments  -  planned:  the  progress  payments 
that  were  planned  to  have  been  made  to  the  contractor 
to  date; 
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.  estimate  to  complete  curves:  for  each  of  the  curves 
previously  described  showing  actual  data,  an  estimate 
to  complete  may  be  added,  when  desired,  to  show  pro¬ 
jected  progress; 

.  schedule  trend  curve:  shows  the  monthly  slack 
estimate  for  the  key milestone  or  milestones  on  the 
project  (usually  project  completion) . 

Part  3:  Financial  Status 

The  PROJECT  COST  STATUS  and  PROJECT  FISCAL  STATUS 
shown  in  Part  3  contain  data  identical  to  that  in  the  Projec 
Summary  Report,  with  the  exception  that  the  cost  trend 
column  is  not  used.  In  Part  3,  the  total  project  is  sub¬ 
divided,  using  the  Work  Breakdown  Structure,  into  the  major 
items  of  work.  Financial  reporting  is  provided  for  each  of 
these  major  items  of  work. 

The  columns  and  headings  for  Part  3  are  ;»s  follows: 

.  DESCRIPTION :  contains  the  descriptive  titles  of 
the  project  and  of  each  item  of  work; 

.  CONTRACT  TYPE:  identifies  the  type  of  contract (s) 
used  on  the  project.  An  "F"  indicates  a  firm  price 
contract;  an  "R"  indicates  a  cost  reimbursable  con¬ 
tract;  an  "M"  indicates  a  combination  of  firm  price 
and  cost  reimbursable  contracts; 

•  WBS  NO . :  identifies  the  items  of  Work  Breakdown 
Structure,  by  number; 

•  RESP  ORGN :  identifies  the  organization  responsible 
for  each  item  of  work; 

.  PROJECT  COST  STATUS  -  TO  DATE: 

.  ACTUAL :  shows  the  cumulative  actual  costs 
incurred  by  the  project  to  date; 

.  PLANNED:  shows  the  cumulative  planned  costs 
to  be  incurred  by  the  project  to  date  and  is  the 
basis  for  comparing  actual  and  planned  costs; 

*  VAR.  $ :  shows  the  amount  in  the  ACTUAL  column 
min ,;s  the  amount  in  the  PLANNED  column,  in  dollars; 
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.  VAR.  %:  shows  the  VAR.  $  over  the  PLANNED  column 
x  lbO ; 

.  PROJECT  COST  STATUS  -  AT  COMPLETION; 

.  LATEST  ESTIMATE :  shows  the  Project  Manager's 
latest  total  project  cost  at  completion  and  is 
based  on  data  from  all  sources; 

.  BUDGET :  shows  the  approved  budget  for  the  project 
and  is  the  basis  for  comparing  the  LATEST  ESTIMATE 
and  the  budget; 

•  VAR.  $:  shows  LATEST  ESTIMATE  minus  the  BUDGET; 

•  VAR.  % •  shows  VAR.  $  over  BUDGET  x  100; 

•  PROJECT  FISCAL  STATUS  -  CASH  THIS  FISCAL  YEAR; 

•  FORECAST :  shows  tne  Project  Manager's  total 
forecast  of  cash  payments  to  be  made  in  the  current 
fiscal  year; 

•  BUDGET:  shows  total  budgeted  cash  payments  to 
Be  macfe  in  the  current,  fiscal  year  and  is  the 
basis  for  comparing  forecast  and  budget  costs. 

•  VAR •  $ :  shows  FORECAST  column  -  BUDGET  column. 

Part  4:  Schedule  Status 

Part  4  shows  in  tabular  form,  the  actual  schedule  status 
of  the  project  and  the  expected  schedule  of  the  project,  to 
provide  an  overall  picture  of  the  timing  of  actual  and  expected 
accomplishments.  The  column  and  headings  for  Part  4  are  as 
follows : 

.  MILESTONE  DESCRIPTION:  shows  the  descri  ive  title 
for  each  major  milestone.  The  milestones  are  grouped 
under  the  same  major  items  of  work  identified  in  Part 
3,  so  that  schedule  status  for  each  major  item  can  be 
compared  with  financial  status  for  analysis; 

.  WBS  NO . :  shows  the  numerical  identification  for  the 
Work  Breakdown  Structure  item; 

•  *ST  NC . :  shows  the  numerical  identification  for  the 
ml  lc stone  being  reported; 
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.  RESP  ORGN:  shows  the  organization  responsible 
for  accomplishing  the  milestone; 

•  SCHE1).  VAR.  (WEEKS) ;  shows  the  scheduled  date 
minus  the  actual  date  or  the  scheduled  date  minus 
estimated  date,  in  weeks; 

.  CALENDAR  YEAR :  the  project  schedule,  shown  in  the 
center  of  the  page,  indicates  for  each  milestone 
its  scheduled  date  (shown  as  £) ,  its  actual  com¬ 
pletion  date  (shown  as  A) ,  and  its  estimated  com¬ 
pletion  date  (shown  as  H  ) .  Milestones  at  which 
an  explicit  report  of  status  of  technical  progress 
will  be  made  are  circled; 

.  SCHEDULED  DATE;  shows  the  actual  completion  date 
of  the  milestone; 

.  ACTUAL/ESTIMATED  DATE:  shows  the  actual  completion 
date  or  estimated  completion  date  of  the  milestone. 


Part  5:  Problem  Analysis 

In  Part  5  any  problems  related  to  the  cost,  schedule, 
or  technical  status  sections  of  the  report  or  problems  as 
reported  by  other  sources  are  described.  For  each  problem. 
Part  5  should  present: 

.  a  concise  statement  of  the  problem; 

.  a  description  of  the  impact  of  the  problem  on  the 
project ; 

.  recommended  action  or  action  being  taken  to  resolve 
the  problem. 
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PROJECT  MANAGEMENT  REPORT 


PART  1i  PROJECT  DESCRIPTION 


PROJECT  TIT.E. 


PRO.  NUMRER. 


RESPONSIBLE  ORGANIZATION. 


PROJECT  VALUE. 


PROJECT  MANAGER. 


PROJECT  TYPE. 


REPORT  DATE. 


name  OP  PRIME  CONTRACTOR!*)  I  QUANTITY  A  ITEM  TO  BE  DELIVERED  I  VALUE  OP  CONTRACT(S) 


name  OP  SU6-CONTRAC  TOR'S-  I  OUANTl’  -  A  ITEM  TO  BE  DELIVERED  I  VALUE  OP  SUB-CONTAACTI$) 


PROJEC’  DESCRIPTION 


FIGURE  B.3 
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FIGURE  P.I  (continued) 
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PROJECT  TVFE _ _  PERT  S;  FltUHClAL  STATUS 
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PART  3;  FINANCIAL  STATUS 


REPORT  DATE  _ 

REPORT  LEVEL _ 

DATA  CURRENT  AS  OF. 


PROJECT  COST  STATUS  $(000) 


TO  DATE 


AT  COMPLETION 


PROJECT  FISCAL  STATUS  $(000) 


CASH  THIS  FISCAL  YEAR 


ACTUAL  |  PLANNED  VAR. $  [  VAR .  S 


LATEST 

ESTIMATE 


BUDGET  VAR. S  VAR.  %  FOPECAST  BUDGET  VAR.  S 


PART  4;  SCHEDULE  STATUS 


CALENDAR  YEAR 


SCHEDULED  ACTUAL 
^ATC  ESTIMATED 

‘'ATE  DATE 


WBS  •  Work  Breakdown  Structure 
MST  •  Mileitone 


/\  Mileitone  Schedule 

A  Mileitone  Actual  Completion  FIGURE  B.3 

-w  Mileitone  Eitimated  Completion  (continued) 
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PROJECT  MANAGEMENT  REPORT 

PART  5  PROBLEM  ANALYSIS 

PRO.  number 

PROJECT 

PROJECT  TYPE 

RE  PORT  l  F  VFL 

REPORT  DATE 

_ — » 

DATA  CURRENT  AS  OE 

PROBLEM  ARC*  ITEM 


FIGURE  B.3  (continued) 
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APPENDIX  C 

PROCEDURAL  CHECKLISTS 


The  Management  Information  Systems  Directorate  is 
responsible  for  processing  life-cycle  documents  for  the 
various  systems  that  it  reviews  and/or  approves.  These 
doucments  both  describe  the  systems  themselves  and  indicate 
the  completion  of  significant  system  development  efforts. 

In  the  same  way  that  the  phases  of  a  system's  life-cycle 
build  upon  preceding  work,  the  processing  of  each  document 
is  predicated  on  earlier  processing,  reviews,  and  evalua¬ 
tions.  Thus,  the  quality  of  life-cycle  management  depends 
on  the  correct  processing  of  these  documents.  This  appendix 
explains  the  processing  procedures  ror  documents  submitted 
to  MISD. 

Each  procedural  checklist  consists  of  items  that  should 
be  performed,  considered,  or  resolved.  The  procedures  for 
a  given  document's  processing  are  dictated  by  the  decisions 
required  during  its  review  or  evaluation;  the  decision  cri¬ 
teria  for  a  particular  situation  are  determined  by  using  the 
procedural  checklists  to  guide  the  evaluation  process  and  to 
satisfy  the  functional  activities'  needs  and  management  cri¬ 
teria  of  MISD.  The  checklists  presented  here  are  designed 
to  be  used  as  part  of  the  analysis  procedures  described  in 
Section  VI.  The  recommendations  included  in  Section  VIII 
are  specifically  designed  to  provide  data  for  these  analyses. 

As  discussed  earlier,  documents  must  qualify  their 
systems  in  two  ways:  (1)  on  their  own  merits,  as  rational 
approaches  to  effectively  meeting  stated  system  needs;  and 
(2)  within  the  context  of  the  Army's  larger  needs  and  the 
manner  in  which  these  are  provided  for  through  existing 
and  proposed  systems.  That  is,  each  system,  through  its 
documentation  must  be  evaluated  by  MISD  in  terms  of  its  own 
integrity  and  its  cost  effectiveness  vis-a-vis  its  impact 
on  the  Army  and  the  Army  Management  Information  System. 


Reporting  System  Requirement 

In  evaluating  the  merits  of  a  proposed  system,  the 
Reporting  System  Requirement  (RSR)  is  analyzed  to  review 
the  purpose  and  need  for  the  system,  expected  system  per¬ 
formance,  how  its  services  are  to  be  provided,  and  what  its 
development  and  operation  wil1  involve.  The  following  check¬ 
list  is  used  in  this  evaluation: 
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check  RSR  for  overall  completeness  of  the  infor¬ 
mation  needed  for  review  and  evaluaHon; 

examine  system  background  to  obtain  an  under¬ 
standing  of  the  context  of  the  need  for  the 
system,  the  problems  to  be  solved  by  the  system, 
and  the  manner  in  which  the  system  will  satisfy 
the  need  or  alleviate  the  causes  of  problems. 

The  background  must  be  related  to  the  goals  of 
the  user  organization,  the  system  goals,  and 
the  functions  to  be  performed;  that  is,  there 
must  be  a  clear  "fit"  between  the  system  and 
the  context  of  its  requirement; 

compare  functions  to  be  performed  by  the  system 
with  system  objectives,  to  ensure  that  system 
development  is  reasonable  and  desirable,  and 
determine  how  the  benefits  that  justify  the 
system  are  to  be  provided; 

ensure  that  the  system's  components  interface 
without  conflict; 

examine  the  data  flow  and  its  processing  re¬ 
quirements  and  procedures  for  completeness, 
quality  control,  and  volume; 

perform  a  cost-benefit  analysis  (considering 
alternatives)  of  the  system  or  review  results 
of  submitted  analyses: 

relate  cost-benefit  analysis  to  the  scope  of 
the  development  effort,  including  an  estimate 
of  the  effort  needed  to  mechanize  and  re¬ 
mechanize  source  data; 

examine  the  communications  requirement  media 
and  methods  within  and  between  data  processing 
installations,  and  compare  these  with  Army 
communications  plans; 

consider  the  use  of  existing  computer  utilities 
and  excess  equipment,  if  acquisition  of  computers 
is  involved; 

analyze  contribution  of  data  elements  to  final 
products  and  system  requirements ; 
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.  make  certain  that  the  required  information  is 
not  available  elsewhere; 

.  determine  if  sampling  techniques  can  replace 
exhaustive  data  collection; 

.  estimate  the  effort  and  resources  needed  to 
supply  input  data; 

.  be  satisfied  that  the  information  and  reporting 
frequency  will  continue  to  be  required; 

.  examine  other  developments  and  RSRs  to  determine 
if  a  combination  or  other  modification  of  system 
plans  is  warranted; 

.  make  certain  that  data  cost  volumes ,  accuracy, 
and  precision  are  commensurate  with  system 
requirements  and  values; 

.  review  comments  and  recommendations  of  monitoring 
agency  and  other  reviewing  or  interested  organi¬ 
zations  ; 

.  ensure  that  security  provisions  are  considered. 

The  second  and  more  important  part  of  RSR  reviews  in¬ 
volves  gauging  the  system's  effect  on  the  AMIS  and  on  other 
developments  within  the  Army  that  might  not  be  known  to  the 
submitting  organization.  Many  of  the  improvement  projects 
will  be  replacing,  modifying,  or  obviating  the  need  for 
existing  systems  and  will  therefore,  require  coordination. 

In  addition,  because  many  resources  may  have  to  be  diverted 
from  existing  systems,  it  might  be  desirable  to  create  a 
competition  among  different  projects  for  the  scarce  resources 
available.  Finally,  all  projects  must  be  coordinated  to 
reduce  the  chance  of  duplication  and  false  starts  and  to 
ensure  compliance  with  broad  Army  plans.  The  checklist  for 
evaluating  the  impact  of  a  proposed  system  is  as  follows: 

.  compare  functions  tc  be  performed  by  proposed 
system  with  those  of  existing  and  other  pro¬ 
posed  systems,  checking  for  excessive  dupli¬ 
cation  of  data  and  functions; 

.  estimate  the  financial  (e.g.,  resource  assignments) 
and  technical  changes  required  in  affected  systems, 
sources  of  funds  and  facilities,  and  the  need  for 
and  effect  of  Program  Change  Requests; 
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.  estimate  the  effects  of  changes  in  workload  at 
data  processing  installations  an<T”on  communica¬ 
tions  facilities; 

.  examine  changes  in  training  and  personnel  assign¬ 
ments  necessary  to  support  the  system's  life  cycle; 

.  compare  system  functions  and  goals  with  those  of 
the  Army  and  AMIS,  and  examine  the  life  expectancy 
of  system  requirements; 

.  compare  equipment  and  facility  requirements  with 
planned  procurements; 

.  to  standardize  and  integrate  systems,  ensure 
compliance  with  ongoing  efforts ,  with  particular 
reference  to  technological  developments. 

The  results  of  the  RSR  review  and  evaluation  are  pro¬ 
vided  to  the  submitting  HQDA  staff  agency  by  letter.  Because 
the  system  under  consideration  is  only  a  preliminary  concept, 
the  review  results  do  not  indicate  approval/disapproval. 
Rather,  they  indicate: 

.  potential  problems,  such  as  insufficient 
development  resources,  that  might  hinder 
or  preclude  attainment  of  objectives; 

.  undesirable  duplications  of  effort,  system 
functions,  etc.; 

.  AMIS  and  Army  considerations  such  as  other 
requirements  or  projects,  conflicts  with  the 
desired  forms  and  structure  of  systems,  and 
impact  of  technological  innovations; 

.  other  developments  and  considerations  of  interest; 

.  suggested  modifications  to  the  information  re¬ 
quirements  or  system  concept  in  light  of  the  above. 

Reporting  System  Specification  (RSS) 

In  evaluating  the  merits  and  impact  of  the  proposed  sys¬ 
tem,  the  Reporting  System  Specification  (RSS)  is  reviewed. 
This  review  includes  consideration  of  the  particular  Guidance 
and  Reporting  System,  the  way  in  which  it  will  impinge  upon 
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AMIS  at  each  step  in  the  procedure,  and  conflicts  between 
the  two.  This  review  is  based  on  the  following  checklist 
items : 


.  examine  system  to  determine  if  the  system 
concept,  requirements  ,  assumptions,  justi¬ 
fication,  etc.,  differ  significantly  from 
those  approved  for  the  RSR; 

.  review  the  approach  for  system  development, 
implementation,  and  operation  for  complete¬ 
ness,  financial  stability,  and  the  feasi¬ 
bility  of  the  implementation  schedule; 

.  determine  the  adequacy  of  the  system  justi¬ 
fication  by  a  cost-benefit  analysis ,  that 
places  emphasis  on  the  system's  contribution 
to  management  in  relation  to  direct  and  in¬ 
direct  incremental  costs; 

.  review  responsibility  assignments ; 

.  review  system  specifications  for  complete¬ 
ness,  feasibility,  and  adequacy; 

.  determine  availability  of  communications 
requirements ; 

.  produce  the  Operating  Information  System 
Directive; 

.  inform  the  Controller  of  the  Army  of  require¬ 
ments  for  facilities  and  equipment. 


Operating  Information  System  Requirement 

In  evaluating  the  merits  and  impact  of  a  proposed  sys¬ 
tem,  the  following  checklist  items  are  used  in  the  review 
of  the  Operating  Information  System  Requirement  (OISR) : 

.  check  OISR  for  inclusion  of  information  needed 
for  the  particular  review  and  evaluation; 

.  examine  background  information  to  gain  an  under- 
standing  of  the  needs  of  and  problems  surrounding 
the  system,  including  an  examination  o2  circum¬ 
stances  leading  to  causal  situations,  such  r.s  why 
uncertainties  exist; 
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relate  the  background  with  the  goals  of  the  user 
organizations,  the  system's  goals,  and  the  func¬ 
tions  to  be  performed.  There  must  be  a  clear 
"fit"  between  the  system,  its  products,  and  the 
context  of  its  requirement; 

ensure  that  a  valid  analysis  was  performed  in 
producing  the  OISR; 

determine  if  the  requested  information  pro¬ 
ducts  and  services,  if  provided,  would  correct 
problem  situations,  fulfill  stated  needs,  or 
reduce  existing  uncertainties,  emphasizing 
specifically  how  the  benefits  used  to  justify 
the  system  will  occur; 

analyze  the  contribution  of  data  elements  to 
final  products;  ~ 

determine  the  practicality  of  providing  source 
data,  taking  into  consideration  the  effort  and 
resources  required  by  individuals,  frequency 
of  inputs,  the  incentive  that  individuals  and 
organizations  will  have  for  providing  data 
(e.g.,  how  they  will  benefit)  definitional  problems, 
accuracy /precision,  etc.; 

examine  the  flow  of  data  and  the  requirements 
and  procedures  for  its  processing  for  complete¬ 
ness,  quality  control,  and  volume;  note  if 
unnecessary  reentry  of  data  into  mechanized 
media  occurs; 

ensure  that  the  system's  components  interface 
effectively; 

examine  the  cot.jnuni cations  requirements  media 
and  methods  within  and  between  data  processing 
installations ,  and  compare  these  with  Army 
communications  plans; 

perform  a  cost-benef it  analysis  of  system, 
including  an  analysis  of  the  system's  impact 
on  AMIS  and  the  Army; 

analyze  the  scope  of  both  the  development  effort 
and  operations  in  regard  to  the  cost-benefit 
analysis ; 
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.  determine  if  sampling  techniques  can  replace 
exhaustive  data  collection; 

.  be  satisfied  that  the  information  and  reporting 
frequency  will  continue  to  be  required; 

.  consider  the  use  of  existing  computer  utilities 
in  lieu  of  adding  to  local  equipment; 

.  examine  other  developments ,  other  OISRs,  and 
RSRs  to  see  if  modification  of  any  system  or 
resource  plans  is  warranted; 

.  make  certain  that  the  data  cost,  volume, 
accuracy ,  and  precision  are  commensurate  with 
system  requirements  and  values; 

I 

.  review  evaluations ,  comments ,  and  recommenda¬ 
tions  of  the  monitoring  agency  and  other  re-  J 

viewing  or  interested  organizations;  1 

.  ensure  that  security  provisions  and  standards 
are  considered. 

I 

At  this  point  in  the  document  review  process,  MISD 
must  determine  whether  or  not  to  grant  approval  to  proceed 
with  the  system  development.  The  HQDA  proponent  must  be  noti-  j 
fied  of  this  decision  and  supplied  with  supporting  findings.  | 
If  approval  is  predicated  on  meeting  certain  prerequisites  J 

prior  to  the  beginning  of  development,  this  must  be  explained 
and  all  conditions  must  be  detailed.  j 

! 

Additional  guidance  and  information  should  also  be  j 

included  to  cover:  j 

.  potential  problems  <e.g.,  insufficient  resources) 
that  will  hinder  or  preclude  attainment  of  objec¬ 
tives  or  that  will  result  in  inefficiencies; 

.  Army  and  AMIS  considerations  such  as  other  proj-  I 

ects  or  requirements,  technological  innovations,  j 

conflicts  with  the  desired  form  or  structure  of 
management  information  systems,  etc.; 

.  modification  or  redirection  of  the  information 
requirement,  system  concept,  or  development 
approach  because  it  involves  duplication  of  ! 

effort  or  additional  facts  or  occurrences; 

.  other  pertinent  developments  and  considerations.  ! 


J 
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This  information,  included  in  an  Operating  Information 
System  Directive  (OISD) ,  also  grants  authority  to  proceed 
with  the  formulation  of  the  OISDP  and  to  assign  responsi¬ 
bilities.  If  appropriate,  a  project  charter  is  issued  to 
specify  objectives,  rerponsibilities ,  authority,  and 
resources . 

Operating  Information  System  Development  Plan 

For  effective  project  control,  system  users  must  have  a 
clear  understanding  of  end  product  purposes,  when  they  are 
needed,  what  their  resource  implications  are,  and  how  end 
products  will  be  achieved.  The  Operating  Information  System 
Development  Plan  (OISDP)  brings  this  information  together 
at  a  significant  point  in  a  system's  life  cycle.  MISD  must 
make  certain  that  adequate  preparation  has  been  made  to 
commence  actual  development.  Additional  planning  will  still 
be  required  to  ensure  that  schedules  and  contingencies  can 
be  met.  In  its  review  of  the  OISDP,  MISD  is  responsible 
for  the  following: 

.  ensure  completeness  and  overall  quality  of 
OISDP  preparation; 

.  review  adequacy  of  Operating  Information  System 
Specification  anT~OISR,  as  amended,  for  technical 
agreement  with  plans; 

.  make  certain  that  Work  Breakdown  Structure  is 
adequately  identified  arid  described^  Each 
description  should  include  the  content  of  work 
involved,  interim  products,  task  relationships, 
criteria  for  demonstrating  accomplishment  progress 
for  control  purposes,  and  methods  or  approaches  to 
development,  as  necessary; 

.  validate  phased  resource  schedules ,  including 
cost,  manpower,  equipment ,  and  facilities  for 
applicable  fiscal  years.  Major  tasks  should 
have  separate  schedules  that  include  decision 
dates,  beginning/ending  dates,  and  milestones; 

.  review  schedule  of  networks  for  validity  and 
compliance  with  requirements. 
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Operating  Information  System  Specification  (QISS) 

An  Operating  Information  System  Specification  (OISS) 
is  generated  for  each  OIS.  The  OISS  is  the  design  baseline 
from  v/hich  individual  development  tasics,  such  as  an  appli¬ 
cation  ,  are  generated;  it  includes  in  one  document  package 
all  technical  design  specifications  needed  for  a  single  OIS. 
The  review  and  evaluation  of  the  OISS  is  therefore  more 
technically  oriented  than  that  of  other  documents,  and  the 
level  of  detail  varies  for  each  system.  It  is  extremely 
important,  however,  that  MISD  not  be  overly  concerned  with 
detail,  but  rather  concentrate  on  judging  the  quality  of 
the  specif icntion  and  on  assuring  tlut  adequate  preparations 
for  producing  a  system  are  included. 

Each  JISS  must  be  related  to  its  predecessor  documents. 
Because  the  situation  that  initially  provided  a  system  justi¬ 
fication  might  have  changed,  it  is  necessary  to  verify  the 
requirement  definition  and  to  build  the  review  and  evaluation 
of  each  OISS  on  this  basis.  Again,  each  system  must  be 
evaluated  both  on  its  own  merits  and  from  an  AMIS  perspective. 

When  a  system  design  has  been  approved  by  MISD,  the  OISS 
supersedes  the  OlSR  as  the  system  baseline.  This  approval 
represents  the  granting  of  authority  to  build  the  system, 
in  accordance  with  project  plans  for  accomplishment  as 
approved.  In  evaluating  the  OISS  prior  to  approval,  MISD 
must  consider  the  following  questions. 

.  Will  the  system  specified  provide  the  infor¬ 
mation  required? 

.  Do  the  results  of  cost-benefit  analysis  demon¬ 
strate  the  value  of  continuing  development? 

Are  life-cycle  costs  comparable  wi*~h  those  for 
system  development  efforts  of  similar  ;cope? 

.  Has  the  situation  originally  just: fyinq  the 
system  altered  significantly? 

.  Are  the  OISD  requirements  still  valid? 

.  Does  work  to  be  accomplished  by  contractors 
conform  to  policy? 

•  Are  security  procedures  adequate? 

.  Are  data  verification  and  editing  procedures 

appliecTat  the  initial  points  o*  entry  into  system? 
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.  Is  configuration  control  provided  for? 

.  Do  quality  control  procedures  provide  for  devel¬ 
opment,  including  audit  trails,  and  control  over 
data  communication? 

.  Are  plans  included  for  discontinuance  of 
systems  no  longer  required? 

.  Is  compliance  with  standards  for  documentation, 
programming,  data  elements ,  communications,  etc., 
provided? 

.  Are  provisions  made  for  the  additional  workload 
at  data  processing  installations  that  are  not 
being  provided  additional  capabilities  for  the 
system? 

.  Are  plans  included  for  necessary  operating 
resources ,  including  facilities,  equipment, 
personnel,  funding,  consumables,  etc.? 

.  Is  action  assigned  for  obtaininq  approval  from 
the  report  control  system? 

.  Is  the  OISS  acceptable  as  a  baseline  design? 

.  Are  system  objectives  defined  in  terms  of 
design  objectives? 

.  Is  the  Work  Breakdown  StrucLuie  complete? 

.  Are  there  time  requirements ,  such  as  response 
times,  that  are  critical  to  system  performance? 

*  Is  wor>c  expansion  under  mobilization  or  other 
work  expansions  taken  into  account? 
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Project  Summary  Reports  and  Project  Management  Reports 

The  Project  Summary  anu  Project  Management  Reports 
bring  together  progress  and  status  data  for  each  project / 
study.  These  reports  are  used  by  MISD  not  only  to  keep 
informed  on  the  various  developments  1  activities,  but, 
more  important,  to  identify  problems  that  could  hinder  or 
present  project  accomplishment.  Or. ly  the  Project  Summary 
Report  is  provided  to  MISD  as  a  matter  of  course;  the 
Project  Management  Report  is  provided  on  request,  in  situa¬ 
tions  calling  for  an  additional  level  of  detail. 
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Members  of  the  MISD  staff  should  examine  the  Project 
Summary  Report  to  learn  the  variances  and  trends  for  projects/ 
studies.  The  review  criteria  used  are  cost  and  time,  with 
special  importance  attached  to  changes  between  planned  and 
"actuals."  Equally  important  are  changes  in  trends.  These 
can  show  the  beginnings  of  problems,  by  disclosing  the  rate 
of  increases  in  funds  or  time  to  complete  projects  as  indi¬ 
cated  during  that  reporting  period,  and,  in  addition,  by 
revealing  any  acceleration  of  the  increases  ever  past  re¬ 
porting  periods. 

The  reports  identify  key  problems  obstructing  progress. 
However  these  problems  and  other  report  data  cannot  be  exam¬ 
ined  absolutely;  the  evaluations  must  consider  relative 
influencing  factors.  For  example,  the  meanings  of  variances, 
which  are  basically  estimates,  differ  according  to  the 
quality  of  the  planning  data.  Assuming  that  these  estimates, 
merely  because  they  are  "plans,"  are  "requirements"  can  lead 
to  an  exaggerated  effect.  In  addition,  since  the  reports  are 
submitted  periodically,  short-term  fluctuations  cannot 
always  be  regarded  as  potential  trends;  a  reporting  period 
is  short  in  relation  to  the  period  over  which  a  project 
accomplishes  its  tasks  or  th-'  Deriod  over  which  bills  are 
paid.  On  the  other  hand,  a  small  variance  as  indicated  in 
one  report  could  be  the  "tip  of  the  iceberg,"  revealing  a 
potential  problem  that  could  be  resolved  by  early  corrective 
action.  In  this  regard,  the  impact  of  slippage  in  one  task 
upon  another  and  upon  the  entire  project  must  be  considered 
during  .nalysis. 

It  is  cl  primary  importance  that  reports  be  interpreted 
to  obtain  their  true  significance;  overreaction  at  the  level 
and  political  position  of  MISD  can  be  harmful.  If,  after 
examination  of  the  Project  Summary  Report,  it  is  felt  that 
a  potential  problem  exists,  the  Project  Management  Report 
should  be  obtained.  Because  of  the  level  of  the  problem 
with  which  MISD  is  concerned,  time  should  be  available  for 
this.  At  the  same  time,  however,  personal  contacts  through 
telephone  calls  and  visits  arn  important  in  obtaining  further 
explanations  of  and  data  about  a  pr  blem  area. 

It  is  in  this  personal  liaison  with  monitoring  agencies 
an^  other  project  management  organizations  that  MISD's  posi¬ 
tion  is  most  sensitive.  The  reporting  of  problems  requires 
the  cooperation  and  confidence  of  the  project  organi zations , 
and  the  best  way  to  ensure  this  is  for  these  organizations 
to  realize  the  oenefits  of  reporting  a  problem  as  soon  as 
it  is  detected,  especially  if  it  involves  a  shortage  of 
resources.  Although  MISD  does  not  directly  control  resources, 
the  manner  in  which  it  makes  its  recommendations  does  affect 
their  allocation. 
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Project  Summary  Report 

In  reviewing  the  Project  Summary  Report,  MISP  must: 

.  study  the  narrative  statement  and  relate  it  to 
available  data; 

.  determine  meaning  of  variances  by: 

.  comparing  the  present  report  with 
previous  reports; 

.  relating  percentages  to  absolute  values; 

.  determining  the  potential  impact  of  variances 
on  future  project  progress  and  completion; 

.  note  potential  shortages  and  action  taken  or 
required  to  relieve  them; 

.  determine  the  meaning  of  trends  by: 

.  comparing  the  present  report  with 
previous  reports; 

.  deciding  if  an  apparent  trerd  might  be  only 
a  temporary  or  insignificant  fluctuation; 

.  determining  the  impact  of  trends  on  fi ture 
project  progress  and  completion; 

.  determining  why  circumstances  exist  that 
force  deviations  from  plans; 

.  relate  the  data  presented  to  previously  known 
problems  of  cost  and  schedule  and  determine 
the  nature  of  problems  and  causes  and  any 
potential  effects  they  might  have  on  performance ; 

.  determine  what,  if  any,  other  information  is 
needed  for  analysis  and  decisions;  obtain 
needed  Project  Management  Reports;  and  locate 
other  information  sources; 

.  decide  action  needed  to  relieve  problems  by : 

.  deciding  how  best  to  achieve  desired  results, 
such  as  intervention  by  Assistant  Vice  Chief 
of  Staff,  redirection  o£  moni  ^ring  agency, 
reassignment  of  critical  resources  by  owners,  etc. 
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.  defining  and  clarifying  the  issues,  focusing 
the  attention  of  responsible  managers  on  the 
problems  at  the  lowest  organizational  level 
having  authority  to  act,  and  giving  support, 
coordination,  and  movement  to  ensuing  actions. 

Project  Management  Reports 

The  Project  Management  Report  contains  an  expansion 
of  the  data  provided  in  the  Project  Summary  Report  and  is 
used  in  the  same  manner  as  that  report.  If  the  Project 
Management  Report  is  required  on  other  than  a  one-time  basis 
for  a  given  project,  arrangements  must  be  made  with  the 
System  Manager. 

Program  Change  Requests 

MISD  does  not  act  on  Program  Change  Requests  (PCR) ,  but , 
since  they  represent  an  important  mechanism  for  obtaining 
resources,  does  retain  an  interest  in  the  progress  of  these 
requests . 

Application  Specifications  and  Other  System  Documentation 

The  application  specifications  are  the  delivered  product 
and,  therefore,  serve  as  indicators  of  project  performance 
quality.  These  documents  are  examined  f-^r  their  quality, 
comprehensiveness,  and  adequacy.  This  examination  cannot, 
of  course,  be  considered  as  the  sole  indicator  of  performance 
The  prime  performance  criterion  is  whether  or  not  the  speci¬ 
fication  provides  for  all  design  requirements. 
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APPENDIX  D 


DRAFT  AR  18-xx 

MANAGEMENT  INFORMATION  SYSTEMS 


This  appendix  contains  a  copy  of  AR  18-xx,  an  Army 
regulation  prepared  in  draft  form  by  Peat,  Marwick,  Liv¬ 
ingston  &  Co.  and  submitted  to  the  Management  Information 
Systems  Directorate  on  August  30,  1968.  The  page  numbers 
of  the  original  regulation  have  been  changed  here  to 
identify  the  sections  of  the  regulation  as  part  of  a  total 
appendix  to  this  document.  Except  for  this,  however,  the 
regulation  appears  here  exactly  as  it  was  originally  pre¬ 
pared.  This  means  that  the  table  of  contents  on  the  fol¬ 
lowing  pages  can  be  used  only  as  reference  for  information 
contained  in  the  regulation,  not  as  an  indication  of  the 
location  of  this  information.  In  addition,  references  to 
sections  of  the  regulation  and  to  illustrations  have  not 
been  changed  from  the  original  submission. 
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SECTION  I 


GENERAL 


1-1.  Purpose 

The  purpose  of  this  regulation  is  to  set  forth  re¬ 
sponsibilities  and  procedures  for  managing  management 
information  systems  throughout  their  life  cycle,  includ¬ 
ing  requirements  definition,  development,  and  operation 
and  maintenance. 

1-2 .  Objectives 

a.  The  primary  objectives  of  this  regulation  are: 

(1)  to  provide  effective  information 
support  to  management  functions  at 
each  command  management  echelon. 

(2)  to  improve  the  utilization  of  scarce 
resources  for  systems  development  and 
maintenance  in  conformity  with  the 
priority  of  the  management  functions 
being  served; 

(3)  to  reduce  the  lead  time  from  initial  con¬ 
cept  definition  to  implementation  of 
management  information  systems;  and 

(4)  to  obtain  maximum  standardization  of 
information  system  design  and  facili¬ 
tate  centralized  programming. 
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b.  These  objectives  will  be  attained  through: 


(1)  clear  statement  and  definition  of  infor¬ 
mation  requirements  at  the  outset; 

(2)  more  effective  participation  of  informa¬ 
tion  users  in  the  design  and  development 
process; 

(3)  continuous  review  and  monitoring  of 
technical  progress  through  each  phase 
of  the  system  life  cycle; 

(4)  estimation  of  resource  requirements 
based  on  initial  plans  and  continuous 
reestimation  of  cost-to-complete  as 
the  project  progresses;  and 

(5)  monitoring  resource  utilization  through 
all  phases  of  the  life  cycle. 

1-3 .  Definitions 

a.  Guidance  and  Reporting  System  (G&RS) .  A  structured 
set  of  information  processing  applications,  gathering  data 
at  its  source,  transforming  it  to  information,  and  deliver¬ 
ing  it  to  some  information  user  or  users,  thus  providing 
a  basis  for  managerial  action  and  downward  transmission 
of  guidance.  A  Guidance  and  Reporting  System  will  ordinarily 
encompass  several  geographically  or  organizationally 
separated  stages  at  which  information  is  gathered,  collated, 
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reduced,  or  otherwise  processed.  These  stages  are  termed 
processing  levels  or  reporting  levels. 

b.  Application .  A  set  of  procedures  including 
computer  programs  where  appropriate,  to  solve  a  particu¬ 
lar  problem  or  set  of  problems. 

c.  Standard  Application.  A  standard  application  is 

a  computer  supported  application  which  is  centrally  designed 
and  developed  (including  computer  programming)  for  use  at 
two  or  more  DPI's. 

d.  Set  of  Standard  Applications.  A  sr  of  two  or 
more  standard  applications  developed  centrally  as  part  of 
a  single  project  for  use  at  two  or  more  DPIs. 

e.  Independent  Application.  Any  application  which 
does  not  support  a  G&R  System,  whether  or  not  it  is 
centrally  designed  and  developed.  If  centrally  designed 
and  developed  for  use  at  several  DPI's,  it  may  be  termed 
a  Standard  Independent  Application. 

f .  Data  Processing  System  (DPS)  .  A  DPS  is  the  set 
of  applications  at  a  given  DPI. 

g.  Operating  Information  System  (OIS) .  An  OIS  is 
the  set  of  applications  performing  all  the  information 
processing  for  a  given  G&R  System  at  a  given  reporting 
level . 

h.  Nonstandard  Computer  Supported  Application.  A 
nonstandard  computer  supported  application  is  any  application 
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supported  by  computer  which  has  not  been  centrally  designed 
and  developed  for  use  at  several  DPI's. 

i.  PCM  Application.  A  PCM  application  is  an  appli¬ 
cation  supported  by  PCM  equipment  and  manual  procedures. 

j.  Manual  Application.  A  manual  application  is  an 
application  supported  entirely  by  manual  procedures. 

k.  Major  Change  (G&R  System) .  Any  modification  to  a 
G&R  System  which  changes  the  information  content  of  any 
output  report,  source  document,  or  master  file  (format 
changes  which  do  not  affect  content  are  excluded) . 

l.  Major  Change  (Application) .  Any  modification 
to  an  application  which  involves  manpower  utilization 
in  excess  of  six  in-house  man-months  or  contractor  man- 
months  . 

m.  Scientific  and  Engineering  Information  System. 

An  information  system  which  has  as  its  primary  function 
the  performance  of  mathematical  computations  and  numerical 
analysis,  and  vjhich  does  not  produce  reports  in  direct 
support  of  a  Guidance  and  Reporting  System. 

n.  System  Specification  Project.  A  planned  under¬ 
taking  to  develop  a  Guidance  and  Reporting  System  Speci¬ 
fication. 

o.  Application  Project.  A  planned  undertaking  to 
develop  an  application,  standard  application,  set  of 
standard  applications,  etc. 
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p.  Life  Cycle.  The  period  of  existence  of  an  infor¬ 
mation  system.  A  logical  sequence  of  phases  through  which 
a  management  information  system  must  progress;  extending 
from  initial  conception  through  development,  operation, 
and  maintenance,  to  final  phase-out. 

1-4.  Scope 

a.  This  regulation  applies  to: 

(1)  System  specification  projects  to 
develop  Guidance  and  Reporting  System 
Specifications,  reference  Appendix  B-3. 

(2)  Application  projects  to  develop: 

.  standard  applications 

.  sets  of  standard  applications 
.  independent  applications 

.  nonstandard  computer  supported  applications 
.  data  processing  systems 

(3)  Major  Changes  (G4R  System) ,  reference 
paragraph  l-3k;  and  Major  Changes  (Appli¬ 
cation),  reference  paragraph  1-31. 

(4)  Other  changes  to  applications  or  GiR 
Systems,  reference  Appendix  C. 

b.  This  regulation  docs  not  apply  to: 

(1)  Selection,  acquisition,  and  disposition 
of  ADPE  (see  AR  18-XX) 
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(2)  Projects  to  develop  scientific  and  engi 
neering  information  processing  systems, 
except  where  a  project  involves  the 
development  of  both  scientific  and 
engineering  information  processing 
systems  and  management  informa¬ 
tion  systems,  the  provisions  of  this 
regulation  are  applicable  to  ttu  entire 
project;  and 

(3)  Projects  to  support  information  systems 
which  are  designated  as  part  of  the 
WWMCCS  or  1DHS. 


SECTION  II 


RESPONSIBILTTIES 

2-1 .  Assigned  Responsibilities 

The  following  responsibilities  for  execution  of  thi 
regulation  are  established  as  follows: 

a.  OAVCofSA,  MISD 

(1)  approve  the  initiation  of  all  system 
specification,  and  application  projects 
of  major  changes/maintenance  thereto; 

(2)  designate  the  MA  and  RDA; 

(3)  designate  G&R  System  managers  and  appli¬ 
cation  managers; 

(4)  act  as  MA  for  certain  development 
projects;  and 

(5)  assure  overall  coordination  of  plans 
and  status  of  MIS  development  projects. 

b.  HQDA  Staff  Agencies 

(1)  act  as  system  proponent  for  G&R  Systems 
and  applications  oiiginating  at  HQDA: 

(2)  act  as  MA  or,  if  appropriate,  RDA; 

(3)  recommend  RDA; 

(4)  monitor  MIS  operations  in  functional 
area; 

(5)  insure  resources  implications  related  to 
G&R  System  Specification  and  Application 
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projects  are  adequately  considered 
(training,  manpower,  personnel,  communi¬ 
cations,  equipment,  facilities)  and 
being  appropriately  considered  in  pro¬ 
gram/budget  decisions;  and 

(6)  coordinate  approval  actions  with 
OAVCofSA,  MISD. 

c.  Major  Commands 

(1)  carry  out  MA  and  RDA  duties  as  assigned; 

(2)  insure  coordination  of  system  imple¬ 
mentation  at  DPI's  under  command  juris¬ 
diction; 

(3)  assign  development  resources  and  support 
in  accordance  with  project  plans;  and 

(4)  provide  analytic  data  in  response  to 
system  analysis  and  design  requirements. 

2-2 ,  Assigned  Roles 

The  following  is  an  explanation  of  roles  to  be 
assigned  by  OAVCofSA  in  accordance  with  the  provisions  of 
this  regulation. 

a.  System  Proponent.  The  organization  originally 
recognizing  the  requirement  for  a  Guidance  and  Reporting 
System  or  any  application.  The  system  proponent  is 
responsible  for  preparing  the  Letter  of  Intent  IAW 
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paragraph  3-2.  The  system  proponent  of  a  G&R  System 
will  ordinarily  be  responsible  for  development  of  the 
requirements  specification.  The  system  proponent  of 
an  application  may  or  may  not  be  appointed  RDA  for  the 
application  project. 

b.  Monitoring  Agency  (MA) .  The  agency  assigned 

by  OAVCofSA  approval  and  monitoring  responsibilities  for 
development  projects  and  monitoring  responsibilities 
for  operational  information  systems,  to  include: 

(1)  approval  of  G&RSS; 

(2)  approval  of  project  plan,  application; 
design,  application  documentation,  and 
test  records; 

(3)  review  implementation  package; 

(4)  review  progress  report;  and 

(5)  approval  of  change  proposals. 

c.  Responsible  Development  Agency (RDA) .  The  Army  Major 
Command  or  other  agency  assigned  responsibility  for  appli¬ 
cations  projects  to  include: 

(1)  performance  of  developmental  tasks  IAW 
Section  HI  of  this  regulation; 

(2)  preparation  of  application  project  pro¬ 
posal,  application  design  specification, 
application  documentation,  test  plan  and 
record,  and  implementation  package; 
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(3)  preparation  of  project  plan  and  progress 


reports;  and 

(4)  maintenance  of  application  programs 

and  procedures  if  so  directed  by  OAVCofSA. 

d.  Guidance  and  Reporting  System  Manager.  An  indivi¬ 
dual  or  group  assigned  responsibility  for  monitoring  and 
change  control  of  a  Guidance  and  Reporting  System  in  the 
Operations  Phase. 

e.  Application  Manager.  An  individial  or  group 
assigned  responsibility  for  monitoring,  change  control, 
and  program  maintenance  of  an  Application  in  the  Operations 
Phase. 
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SECTION  III 


LIFE-CYCLE  PROCEDURES 

3-1.  General 

This  section  describes  the  management  information 
system  life  cycle,  responsibilities,  tasks,  and  reporting 
requirements.  The  set  of  required  documents  to  be  used 
for  recording  work  outputs,  maintaining  continuity,  and 
obtaining  approvals  as  necessary,  is  included  within  a 
sequence  of  phases  and  constitutes  a  part  of  the  signifi¬ 
cant  work  which  must  be  accomplished  during  a  life  cycle. 

It  is  a  purpose  of  this  regulation  to  make  the  overlapping 
and  interrelated  phases  discrete  by  specifying  their  tasks, 
documentation,  and  procedural  requirements.  These  will 
provide  a  uniform  structure  and  discipline  needed  to  im¬ 
prove  the  management  of  undertakings  to  convert  conceptual 
requirements  into  operational  capabilities.  In  the  remainder 
of  this  section,  the  life  cycle  is  outlined  in  terms  of 
phases,  tasks,  and  documentation  requirements.  In  order 
to  provide  for  adjustment  of  procedural  requirements  to 
suit  the  particular  system  or  project  involved,  all  pro¬ 
posed  development  effort  will  be  initiated  by  the  submis¬ 
sion  of  a  Letter  of  Intent,  describing  the  nature  of  the 
problem  and  the  intended  action.  OAVCofSA  will  review 
the  intended  action,  coordinate  as  required,  and  respond 
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with  guidance  prescribing  the  procedural  requirements 
under  Life-Cycle  Management.  Depending  upon  the  size, 
scope,  and  significance  of  the  project,  exemption  from 
various  procedural  requirements  may  be  granted. 

The  life  cycle  consists  of  eight  phases  in  which 
various  documents  are  produced  as  integral  parts  of  the 
work  output.  The  phases  include  a  problem  analysis  and 
statement  phase,  a  system  specification  phase  for 
guidance  and  reporting  systems  only,  a  set  of  applica¬ 
tion  project  phases,  and  an  operations  phase.  These 
phases,  together  with  the  required  documents  are  shown 
in  Figure  III . 1 . 

3-2 .  Problem  Analysis  and  Statement 

In  this  phase,  an  information  problem  is  analyzed, 
a  problem  statement  prepared,  and  an  intended  course  of 
action  identified. 

a.  Primary  Tasks 

(1)  identify  problems  and  objectives; 

(2)  initiate  problem/system  analysis  to 
determine  causes  of  difficulties  and 
examine  alternate  solutions; 

(3)  develop  conceptual  approach  and  pre¬ 
liminary  plans  for  attaining  objec¬ 
tives  and  resolving  problems: 
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(4)  identify  proposed  course  of  action, 
including  G&R  System  specification, 
application  development,  major 
change,  etc.;  and 

(5)  identify  proposed  reporting  require¬ 
ments  for  life  cycle  man^ement,  IAW 
the  remainder  of  Section  III. 

b.  Required  Documentation  -  Letter  of  Intent 

c.  Responsibilities 

(1)  task  performance  -  system  proponent 

(2)  documentation 

.  preparation  -  proponent 
.  review  -  HQDA  or  commands  as 
appropriate 
.  approval  -  OAVCofSA 

d.  Documentation  Functions.  The  Letter  of  Intent 
is  a  statement  of  intent  to  develop  a  G&R  System  Speci¬ 
fication  or  Application  or  a  Major  Change,  using  in-h-s  :se 
or  contract  capabilities.  This  document  is  reviewed  by 
OAVCofSA  to  identify  the  potential  impact  of  the  proposed 
action  upon  Army  resources  and  on  the  Army  Management 
Information  System.  OAVCofSA  will  provide  guidance  by 
letter,  prescribing  procedural  requirements  for  Life- 
Cycle  Management,  depending  on  the  nature  of  the  proposed 
action.  OAVCofSA  will  also  appoint  a  Monitoring  Agency, 
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or  will  assume  the  role  itself.  Figure  III. 2  shows  for 
each  action  the  organization  which  will  ordinarily  be 
assigned  as  Monitoring  Agency. 

3-3.  Requirements  Specification  (G&R  Systems  Only; 

In  this  phase,  the  requirements  for  information  con¬ 
tent  and  information  processing  are  clearly  stated  to 
provide  a  basis  for  development  of  supporting  applications. 
To  preclude  the  possibility  of  inconsistencies  among  dif¬ 
ferent  data  inputs  due  to  different  methods  of  data  gather¬ 
ing  or  processing,  the  specification  extends  through  each 
processing  level  (OIS)  to  the  uource  of  data, 
a.  Requirements  Specification  Phase 
(1)  Primary  Tasks 

(a)  Develop  concept  and  design  of  the 
G&R  System  and  each  OIS 

(b)  Specify  in  detail  for  each  OIS 
.  data  elements  and  codes 

.  data  flow 

.  processing  requirements 
.  system  output  reports  and  other 
products  and  services 
.  data  sources 
.  data  controls 

(c)  Prepare  preliminary  specification  for 
applied;: ion  testing  '-i  evaluation 
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(d)  Prepare  draft  of  implementing  directive 

(2)  Required  Documentation 

(a)  G&RS  Specification  (GRSS) 

(b)  Draft  Army  Regulation  or  other  directive 

(3)  Responsible  Agencies 

(a)  Task  Performance  -  G&R  System 
proponent 

(b)  Required  documentation 
.  prepare  -  proponent 

.  approve  -  OAVCofSA 

I 

(4)  Documentation  Functions.  The  function  of  the 
GRSS  is  to  provide  a  statement  of  information  content  and 

I 

processing  requirements,  to  provide  a  sound  basis  for 
Application  Development.  OAVCofSA  will  review  the  GRSS 
and,  upon  approval,  will  prepare  and  forward  to  the  systen 
proponent  a  letter  containing  guidance  for  the  preparation 
of  Application  Project  Proposals,  which  will  be  endorsed  I 

I 

by  the  system  proponent  and  forwarded  to  RDAs.  The  draft  ! 

regulation  or  other  directive  outlines  the  regulatory  re-  j 

qu^rements  for  support  of  the  system  and  will  supplement 

1 

the  specification. 

3-4.  Application  Project  Phases  ! 

The  remainder  of  the  development  phases  are  concerned 

with  efforts  to  develop  applications  or  sets  of  applications  I 

1 

! 

j 

j 
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(c)  Application  Project  Directive 


.  prepare  -  MA 

(4)  Documentation  Functions.  The  Application 
Project  Proposal  provides  a  brief  description  of  the 
project,  together  with  a  development  plan  and  preliminary 
technical  description.  It  provides  a  basis  for  approval 
of  the  project  and  for  monitoring  development.  The  tech¬ 
nical  specification  is  preliminary  and  will  presumably 
require  some  degree  of  change  pri  r  to  submission  of  the 
Application  Specification.  The  Application  Project  Direc 
tive  functions  as  a  charter  to  commence  application  devel 
opment.  It  outlines  design  criteria,  time  and  resource 
limitations,  and  other  constraints  under  which  the  Appli¬ 
cation  Project  is  to  proceed, 
b.  Application  Design 
(1)  Primary  Tasks 

(a)  Perform  detailed  application  design 
and  finalize  technical  specification 
for  application. 

(b)  Revise  development  plan  as  necessary 
in  light  of  finalized  technical  speci¬ 
fication,  and  report  progress,  reference 
Appendix  D. 

(c)  Prepare  plan  for  testing  application. 


D .  22 


/<>//.  !/,//  •>  it  A  / ,i  mo  -  ton  ,V  ( 


(d)  Identify  required  communications  capa¬ 
bilities  and  specify  application  inter¬ 
faces. 

( 2 )  Required  Documentation 
Application  Design  Specification 

(3)  Responsible  Agencies 

(a)  Task  performance  -  RDA 

(b)  Application  Design  Specification 
.  prepare  -  RDA 

.  approve  -  MA 

(4)  Documentation  Functions.  The  Application 
Design  Specification  (ADS)  provides  a  base  line  for  pro¬ 
gram  and  procedure  development.  The  technical  specifica¬ 
tion  must  be  prepared  in  adequate  detail  to  permit  "desk 
checking"  (manual  simulation)  of  the  application  logic. 

A  detailed  design  review  is  conducted,  with  the  partici¬ 
pation  of  the  MA  to  assure  that  the  application  will 
support  the  management  information  requirements  it  is 
intended  to  support. 

c.  Program  Development.  In  this  phase,  computer 
programs,  computer  operating  procedures,  and  all  manual 
procedures  are  designed,  developed  (coded),  tested,  and 
documented. 
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(1)  Primary  Tasks 

(a)  Design  and  code  programs 

(b)  Prepare  procedures 

(c)  Test  and  debug  programs 

(d)  Conduct  application  tests 

(e)  Prepare  ADPE  system  specification 
IAW  AR18-2  (if  appropriate) 

(2)  (f)  Report  progress 

(2)  Required  Documentation 

(a)  Program  specification 

(b)  Program  and  application  documentation 

(3)  Responsible  Agencies 

(a)  Task  Performance  -  RDA 

(b)  Application  Documentation 
.  prepare  -  RDA 

.  approve  -  MA 

(4)  Document  Functions.  The  application  specifi¬ 
cation  provides  the  basis  for  developing  operable  programs 
and  procedures.  After  a  detailed  design  review  conducted 
with  the  MA,  program  specifications  are  prepared  by  the 
RDA,  providing  direct  instruction  to  programmers.  When 
programs  have  been  coded  and  tested,  the  application  speci¬ 
fication,  revised  as  necessary,  together  with  the  Program 
Specifications,  revised  as  necessary,  and  Program  Documenta¬ 
tion,  provide  the  basic  elements  for  useful,  maintainable 
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system  documentation.  They  are  combined  to  form  the  Appli¬ 
cation  Documentation. 

d.  Test  and  Evaluation  Phase.  Once  the  programs  have 
been  successfully  tested  individually,  it  is  necessary  to 
conduct  two  further  tests  prior  to  beginning  production  on 
a  regular  basis.  First,  a  System  Test  is  conducted  in 
which  all  programs  are  operated  on  a  run- to-run  basis,  with 
all  interfaces  tested,  using  prepared  test  data.  This  is 
essentially  a  dress  rehearsal.  Following  the  System  Test, 
a  Pilot  Test  is  conducted  wherein  the  application  is 
operated  in  a  production  environment  using  actual  data  and 
producing  actual  outputs.  (Pilot  Test  may  be  conducted 
on  a  parallel  basis  with  the  current  information  system 
if  appropriate.) 

(1)  Primary  Tasks 

(a)  Conduct,  in  sequence 
.  System  Test 

.  Pilot  Test 

to  include  for  each  test 
.  Finalize  Test  Plan 
.  Maintain  Test  Log 
.  Validate  Output 
.  Evaluate  Test 

(b)  Report  Progress 
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(2)  Documentation  Functions.  The  RDA  will  coor¬ 
dinate  with  the  MA  the  plan  for  the  Testing  Phase.  The 
Test  Record  serves  to  record  the  test  plan,  plus  a  log 
of  all  starts,  stops,  errors  discovered,  and  remedial 
action  taken.  When  the  System  Test  has  been  completed, 
the  MA  will  review  and  evaluate  this  record  and,  upon 
approval,  will  authorize  the  RDA  to  commence  the  Pilot  Test. 
When  the  series  has  been  completed  satisfactorily,  the 
MA  will  forward  to  OAVCofSA  an  evaluation  of  the  tests,  to¬ 
gether  with  the  Test  Records  and  recommendation  for  imple¬ 
mentation.  OAVCofSA  will  issue  a  letter  directing  pre¬ 
paration  of  the  implementation  package,  or  directing 
further  testing  or  development  effort. 

e.  Implementation  Phase.  When  pilot  testing  has  been 
successfully  completed,  the  application  is  promulgated  to 
the  various  DPls  which  will  operate  it.  The  DPls  conduct 
local  tests  of  the  application  and  commence  production,  thus 
concluding  the  Application  Project  Phases. 

(1)  Primary  Tasks 

(a)  ADPE  acquisition  and  installation 
(if  appropriate) 

(b)  prepare  implementation  package 

(c)  distribute  implementation  package 

(d)  report  progress  (reference  Appendix  D) 

(e)  conduct  local  application  testing  at  DPI 
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( 2 )  Required  Documentation 

Implementation  Package 

(3)  Responsible  Agencies 

(a)  task  performance  -  Tasks  a-d  -  RDA, 

Task  e  -  DPI 

(b)  implementation  package 
.  prepare  -  RDA 

.  review  -  MA 
.  approve  -  OAVCofSA 

4)  Documentation  junctions.  The  function  of  the 
implementation  package  is  to  promulgate  the  programs  and 
procedures  to  the  supporting  DPI  or  other  activities. 

Upon  receipt  of  the  implementation  package,  the  DPI  conducts 
local  tests  to  assure  local  operability  of  the  application. 

3-:>.  Operations  Phase 

When  the  Implementation  Phase  has  been  completed,  the 
project  loses  much  of  its  identity,  and  the  applications 
are  operated  at  DPIs,  supporting  G*R  Systems  or  local 
information  requirements .  However,  further  effort  of  a 
developmental  nature  may  be  required  to  correct  latent 
program  deficiencies,  or  to  otherwise  improve  the  system 
or  application.  A  system  or  application  manager  is,  therefore, 
appointed  to  assume  responsibility  for  monitoring  the  on¬ 
going  G&R  System  or  application,  and  for  change  control 
(reference  Appendix  C) . 
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APPENDIX  A 
EXPLANATION  OF  TERMS 

To  provide  an  explanation  of  terms  for  use  in  this 
regulation,  it  is  necessary  to  start  with  a  familiar  term — 
application. 

An  application  is  a  set  of  procedures,  including 
computer  programs  where  appropriate,  to  solve  a  particular 
problem  or  set  of  problems. 

Initially  the  discussion  will  center  about  applica¬ 
tions  which  support  Guidance  and  Reporting  Systems — an 
application  is  a  set  of  procedures  (computer,  PCM,  or 
manual)  which  support  a  reporting  system  at  a  particular 
DPI.  There  are  other  types  of  applications,  which  will 
be  considered  later. 

A  specific  application  can  therefore  be  identified 
by  specifying  the  Guidance  and  Reporting  System  it  supports 
and  the  DPI  at  which  it  is  located  (operated) .  For  example. 
Application  0002. S002  would  identify  the  application  to 
support  the  Five  Year  Troop  Bases — Active  Army,  GfcR  System 
(0002)  at  HQUSCONARC  S002. 

There  are,  however,  several  other  identifying  attri¬ 
butes  which  car  usefully  be  attached  to  this  designation. 
First,  the  reporting  processing  level  at  which  the 

G&R  System  is  repo  *hich  will  ordinarily  but  not 
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always  be  the  organizational  level  of  the  DPI.  Thus,  for 
the  above  application,  the  designation  02  is  attached  to 
indicate  the  system  is  supported  at  the  Major  Command 
reporting  level.  This  designation  is  inserted  between 
the  previous  two,  so  that  0002.02.S002  identifies  the 
applications  to  support  the  Five  Year  Troop  Bases  at  the 
Major  Command  Reporting  Level,  at  HQUSCONARC  DPI. 

It  is  also  useful  to  know  if  the  application  is  part 
of  some  "standard  system"  which  has  been  centrally  designed 
and  programmed  to  operate  at  several  DPI's — or  if  not,  by 
what  means  the  processing  is  accomplished;  i.e.,  nonstandard 
computer  application,  PCM,  or,  in  some  cases,  manual  support. 

As  shown  in  the  list  of  codes  in  Figure  A.l,  non¬ 
standard  computer  procedures  are  identified  by  tne  code 
002,  which  is  placed  to  the  right  of  the  other  codes,  so 
that  0002 . 02 . S002 . 002  would  represent  the  same  HQCONARC 
application,  as  previously  noted,  and  would  indicate  that 
the  application  consists  of  nonstandard  computer  procedures. 

Finally,  in  order  to  provide  identification  for  those 
applications  which  are  not  directly  in  support  of  G4R 
Systems,  an  additional  code  is  attached  to  indicate  subject 
area,  such  as  Facilities  Inventory  (0133),  Motor  Vehicle 
Registration  (0196) ,  Dependent  Medical  Care  Progiam 
v0194),  etc.  This  code  is  only  used  when  no  G4R  system 
is  supported,  so  that  0000  will  be  entered  in  the  GtR 
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System  code  position.  Conversely,  if  a  GfcR  System  is 
supported,  the  subject  area  code  will  be  0000,  so  that 
0002. 02. S002. 0000  represents  the  previously  referenced 
HQCONARC  application  to  support  the  Five  Year  Troop  Bases. 
On  the  other  hand,  the  application  for  Motor  Vehicle  Reg¬ 
istration  would  be  numbered  (note  that  reporting  level 
is  000  or  not  applicable)  0000. 02. S002. 000. 0196. 

Thus,  any  application  may  be  identified  by  a  five 
part  number,  as  follows. 


Subject  Area  NA 

Processing  Method 
Nonstandard  Computer 

DPI  HQUSCONARC 


Reporting  Level, 
Major  Command 

GfcR  System 


It  is  possible  to  provide  a  number  of  other  identifications 
for  purposes  of  this  regulation. 

Guidance  and  Reporting  System  (GfcRS) 

A  GfcR  System  is  identified  as  the  set  of  applications 
bearing  a  give.  GfcR  System  number. 
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Operating  Information  System  (OIS) 

An  OIS  is  the  set  of  applications  performing  all  the 
information  processing  for  a  given  G&R  System  at  a  given 
reporting  level.  An  OIS  is  identified  as  the  set  of  appli¬ 
cations  bearing  a  given  G&R  System  number  and  a  given 
reporting  level  number. 

Data  Processing  System  (DPS) 

A  DPS  is  the  set  of  applications  at  a  given  DPI.  A 
DPS  is  identified  as  the  set  of  applications  bearing  a 
given  DPI  number. 

Standard  Application 

A  standard  application  is  a  computer  supported  appli¬ 
cation  which  is  centrally  designed  and  developed  (including 
computer  programming)  for  use  at  two  or  more  DPI's.  Thus, 
a  standard  application  is  identified  as  the  set  of  appli¬ 
cations  bearing  a  given  "processing  method"  number  other 
than  000  (manual),  001  (PCM  supported),  or  002  (nonstandard 
computer  supported) . 

Nonstandard  Computer  Supported  Application 

A  nonstandard  computer  supported  application  is 
identified  as  any  application  bearing  processing  method 
number  002. 

Manual  Application 

A  manual  application  is  identified  as  any  application 
bearing  processing  method  number  000. 
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PCM  Application 

A  PCM  application  is  identified  as  any  application 
bearing  processing  method  001. 

Independent  Application 

Any  application  which  does  not  support  a  G&R  System. 
An  independent  application  is  identified  by  the  G&R  System 
number  0000  and  by  a  non-zero  entry  in  the  subject  area 
position. 

Set  of  Standard  Applications 

A  set  of  two  or  more  standard  applications  developed 
centrally  as  part  of  a  single  project  for  use  at  two  or 
more  DPIs. 

The  following  illustrations  provide  examples  of  the 
above  identified  terms. 

APPLICATION  CODES 

(For  illustration  purposes  only,  not  to  be  used  in 
referring  to  actual  applications.  Reference  TB  18-X, 
"Application  Identification  Code  List,"  for  actual  codes.) 
G&R  Systems 

0000  Independent  Application  -  No  G&R  System 

0002  Five  Year  Troop  Bases,  Active  Army 

Civilian  Pay 


0005 


Reporting  Levels 

01  HQDA 

02  Major  Command 

03  Subcommand 

04  Division/Installation 

DPI's 

A101  HQDA  (USAIDSCOM) 

M002  USAREUR 

R002  USACDC 

S002  HQUSCONARC 

TO 02  USAMC 

S101  HQ  1st  U.S.  Army 

S3 01  HQ  3rd  U.S.  Army 

S401  HQ  4th  U.S.  Army 

S501  HQ  5th  U.S.  Army 

S3 11  U.S.  Army 

5314  U.S.  Army  Garrison,  Ft.  Gordon,  Georgia 

5315  U.S.  Army  Garrison,  Ft.  Jackson,  Florida 

Processing  Methods 

000  Manual 

C01  PCM 

002  Nonstandard  Computer  Supported 

022  COCOAS 
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Subject  Areas  (for  Independent  Applications) 

0097  Facilities  Inventory 

0127  Motor  Vehicle  Registration 

0342  Dependent  Medical  Care  Program 

Explanation  of  Figure  A.l 
Applications 

Each  numbered  box,  e.g.,  0002 . 03 . S101 . 002 . 0000  repre¬ 
sents  an  application. 

G&R  System 

G&R  System  0002  (Five  Year  Troop  Bases,  Active  Army) 
consists  of  all  applications  shown  (not  that  all  are  iden¬ 
tified  by  0002  in  first  position) ,  as  well  as  certain  appli¬ 
cations  omitted  for  lack  of  space,  as  indicated  by  down¬ 
ward  arrow  (i). 

Operating  Information  System 

OIS  0002.02  consists  of  all  the  applications  support¬ 
ing  GS.R  System  0002  at  the  Major  Command  (02)  reporting 
level.  Thus,  OIS  0002.02  consists  of  applications: 

0002. 02. M002. 002. 000 
0002. 02. S002. 002. 000 
0002. 02. R002. 001. 000 
0002. 02. T002. 001. 000 

Similarly,  OIS. 0002. 01  consists  of  the  one  application  sup¬ 


porting  GfcR  System  0002  at  HQDA  level,  namely  0002.01, 
A101.002.00Q. 
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OIS  0002.03  consists  of  applications 
0002. 03. S101. 002. 0000 
0002.03.3301.002.0000 
0002. 03. S401. 002. 0000 

which  are  the  applications  with  G&R  System  0002  at  the  sub¬ 
command  level,  plus  all  the  applications  omitted  from  the 
illustration  which  would  support  G&R  System  0002  at  the 
subcommand  level  within  other  major  commands  (other  than 
CONARC) .  This  would  include 
0002. 03. M101. 002. 000, 

0002. 03. M201. 002. 000,  etc. 

Standard  Application 
Applications 
0002. 04. S311. 022. 000, 

0002. 04. S314. 022. 000,  and 
0002. 04. S315. 022. 000 

are  standard  applications,  as  they  support  the  same  GfcR 
System  (0002)  at  the  same  reporting  level  (.04),  using  the 
same  processing  method  (022) .  A  second  type  of  standard 
application  is  shown  in  Figure  A. 2,  where  independent 
applications 

0000. 04. S311. 022. 0342, 

0000. 04. S314. 022. 0342,  and 
0000. 04. S315. 022. 0342 
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have  the  same  processing  method  and  are  in  the  same  func¬ 
tional  area.  This  latter  standard  application  may  also 
be  termed  "Standard  Independent  Application." 
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SET  OF  STANDARD  APPLICATIONS  022  (COCOAS) 


Explanation  of  Figure  A. 2 


Data  Processing  System  (DPS) 

Each  of  the  boxes  composed  of  dotted  lines  comprises 
a  data  processing  system — the  set  of  applications  at  a 
given  DPI.  Thus,  DPS  S311  consists  of  applications 
0005. 04. S31i. 022. 0000 
0000. 00. S311. 022. 0342 
0002. 04. S311. 022. 0000 
0000. 00. S311. 002. 0097 
0000. 00. S311. 002. 0127 
Standard  Application 

As  in  Figure  A.l,  standard  application  0002.04.xxx. 
022.0000  consists  of  applications 
0002. 04. S311. 022. 000 
0002. 04. S314. 022. 0000 
0002. 04. S315. 022. 0000 
Set  of  Standard.  Applications 

A  set  of  standard  applications  consists  of  two  or 
more  standard  applications  developed  centrally  as  part 
of  a  single  project  for  use  at  several  DPI’s. 

All  the  applications  withir.  the  larger  solid-lined 
boxes  comprise  a  set  of  standard  applications  consisting 
of  : 
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Standard  Application  0002 . 04 .xxx. 022 . 0000 
Standard  Application  0005. 04. xxx. 022. 0000 
Standard  Application  0000. 00. xxx. 022. 0342 
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APPENDIX  B 


INSTRUCTIONS  FOR  PREPARING  REQUIRED  DOCUMENTATION 

B-l.  General  Instructions 

There  are  two  types  of  instructions  in  this  appendix: 

a.  instructions  for  documents  with  document 
formats  and  contents  specified;  and 

b.  instructions  for  documents  for  which  only 
the  minimum  contents  are  described. 

B-2 .  Letter  of  Intent 

Identify  the  problem  analyzed,  and  the  proposed  action 
and  objectives  as  well  as  anticipated  in-house  or  contract 
resource  requirements  (gross  estimate) . 

B-3.  Guidance  and  Reporting  System  Specification  (GRSS) 
a .  Format 

(1)  Identification 

(a)  system  title 

(b)  system  number  (as  assigned  by  OAVCofSA) 

(c)  agency  submitting  G6RSS 

(d)  reference  to  original  Letter  of  Intent 
.  date  and  proposed  title 

.  agency  submitting 
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(e)  reference  to  directives 

(f)  functional  areas  of  information  requirements 

(g)  proposed  MA  for  supporting  applications 

(2)  Background 

(a)  basic  directives 

(b)  general 

(3)  System  Description 

(a)  objectives  of  system 

(b)  functions  to  be  supported 

(c)  scope 

(4)  Supporting  Organizations 

(a)  Army  elements 

(b)  DPIs 

(c)  System  Overview  Chart 

(5)  Information  Content 

(a)  information  and  data  elements 

(b)  data  sources 

(c)  data  flow  chart 

(6)  Other  General  Comments 

(7)  OIS  Specification 

(a)  source  data  groups 

(b)  master  file  descriptions 

(c)  input/output  and  report  specification 

(d)  gross  processing  logic  required- 
manual  or  machine 
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(8)  Development  Approach  for  Applications 


b.  Specific  Instructions.  The  following  instructions 
are  keyed  to  the  item  n’unbers  in  Figure  B-3a. 

Item  1.  Identification 

Item  la.  System  Title.  Self-explanatory. 

Item  lb.  System  Number.  OAVCotSA  will  assign  a 
system  number  on  responding  to  the  Letter  of  Intent. 

Item  lc.  Agency  Submitting.  Self-Explanatory. 

Item  Id.  Letter  of  Intent.  Self-explanatory. 

Item  le.  Reference  to  Directives.  Reference 
related  directives,  whether  or  not  they  are  also  included 
under  2(a). 

I tem  1 f .  Functional  Areas  of  Information  Require¬ 
ments.  Enter  functional  areas  (finance,  logistics,  etc.) 
in  which  the  proposed  G4R  System  will  provide  service. 

Item  lg.  MA.  Enter  name  of  HQDA  staff  agency  or 
other  agency  proposed  by  the  submitting  agency  to  be  MA 
for  supporting  application  projects. 

Item  2.  Background 

Item  2  .  Directives .  Enter  titles  and  numbers  cf 
Army  directives,  including  draft  directives  so  identified, 
which  will  support  tne  G4R  System. 

Item  2b.  General .  Describe  background  and  everts 
leading  to  recognition  of  information  requirement.  State 
why  vhe  requirement  exists,  relating  it  to  organization 
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missions  and  functions.  If  requirement  is  currently  sup¬ 
ported  or  satisfied  in  full  or  in  part  by  an  existing  in¬ 
formation  system,  describe  changes  in  environment  or  in¬ 
adequacies  of  current  system  which  make  it  unsatisfactory 
for  continued  use. 

Item  3.  System  Description 

Item  3a.  Objective  of  System.  State  objective  of 
system  or  system  improvement . 

Item  3b.  Functions  to  be  Supported  by  the  Proposed 
System.  This  system  will  support  the  following  functions: 
State  what  the  products  of  the  system  will  be  used  for  in 
terms  of  functions  supported — e.g,,  monthly  review  of 
expenditures  for  civilian  pay. 

Item  3c.  Scope.  State  scope  of  system,  i.e.,  infor¬ 
mation  functions  encompassed  at  any  processing  level — e.g., 
time  and  attendance  records  for  pay  purposes.  State  the 
extent  of  changes  to  present  procedures  and  information 
systems . 

Item  4.  Supporting  Organizations 

Item  4a.  Army  Elements.  Enter  the  Army  organizations 
which  will  be  required  to  perform  information  processing 
functions  within  this  system.  This  will  include: 

.  data  observation  and  recording 
.  manual  preparation  of  reports 
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.  automated  preparation  of  reports 
.  receipt  and  utilisation  of  reports 
.  other  functions  within  the  system 

Item  4b.  DPIs .  Enter  the  DPIs  by  number  which  will 
perform  data  processing  within  the  proposed  system,  in 
support  of  the  above  organizations. 

Item  4c.  System  Overview  Chart.  Provide  a  chart 
similar  to  the  example  shown  (Figure  A. 3),  portraying  each 
application,  the  applications  to  which  it  provides  data 
or  from  which  it  receives  data,  and  an  indication  of  the 
OIS  specification  which  each  DPI  will  support,  by  reference 
to  the  part  of  Section  7  (A,  B,  C,  D,  etc.)  specifying  the 
OIS.  Identifying  codes  in  applications  will  be  provided 
including  at  minimum  G&R  System  Number;  Processing  Level, 
and  DPI  number  (Ref  TB18-X) . 

Item  5.  Information  Content 

Item  5a.  Information  and  Data  Elements.  Enter  the 
information  and  data  elements  or  data  element  groups  which 


will  be  observed,  recorded,  processed,  and  reported  within 
this  system  (e.g.,  civilian  employee  identification,  hours 
worked  by  week,  absences,  and  leave). 

Item  5b.  Data  Sources.  Enter  the  original  operational 
sources  of  data  for  the  proposed  system,  by  data  element 
or  group.  If  data  is  not  gathered  at  source  within  this 
G&R  System,  but  is  obtained  from  other  information  systems, 
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describe  the  method  of  operation  of  other  systems  up  to  the 
point  where  data  or  information  enters  the  proposed  G&R 
System. 

Item  5c.  Data  Flow  Chart.  Flow  chart,  illustrating 
flow  of  data  from  source,  through  typical  reporting  organi¬ 
zations  for  each  processing  level  to  final  information  user. 

Show  interfaces  with  other  G&R  Systems.  Use  flow  chart 
symbols  as  per  AR  18-7.  State  briefly  the  processing  to 
be  accomplished  by  DPIs.  State  the  communication  media  to 
be  employed. 

Item  6.  Other  General  Comments.  Self-explanatory. 

Item  7.  System  Specification  (Separate  section  lor  each  OIS) 
Item  7a.  Source  Data  Groups 

.  Enter  source  of  data.  (If  not  collected  at  operational 
source,  identify  source  of  data  in  other  informa¬ 
tion  system  and  reference  Item  5b.) 

.  Enter  method  of  observing  and  reporting  showing 
source  document  format  and  general  instruction  for 
preparation. 

Item  7b.  Master  File  Descriptions.  Enter  content, 
record  format,  and  sequence. 

Item  7c,  Input-Output  and  Report  Specifications. 

Include  specifications  of  tape  or  card  files  transmitted 
between  processing  levels,  as  well  as  any  printed  reports. 
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.  Enter  content— information  items  contained. 

.  Enter  format  of  records — show  sample  formats  IAW 
AR  18-7. 

.  Enter  sequence. 

Item  7d.  Processing  Required. 

.  Include  flow  chart  and  narrative  for  gross  processing 
logic. 

.  Include  required  data  controls,  e.g.,  record  counts; 
also  backup  files  required. 

Item  8.  Development  Approach.  Indicate  for  each  DPI 
or  set  of  DPIs  how  it  is  anticipated  that  the  applications 
will  be  developed  (whether  through  individual  development 
projects,  on-going  standard  application  projects,  new 
standard  application  projects,  etc.). 

B- 4  .  Application  Documents 

The  remaining  documents  apply  to  all  application  projects, 
including  DPS  projects,  standard  application  projects,  and 
projects  to  develop  sets  of  standard  applications.  The 
outlines  and  instructions  below  will,  therefore,  be  modified 
as  necessary  to  encompass  the  particular  type  of  project 
involved.  Specifically,  u  is  anticipated  that  within  the 
Application  Project  Proposal  all  items  except  Item  6 — Project 
Plan,  will  be  replicated  for  each  application  within  the 
project.  Similar  items  in  later  documents  will  also  be 
replicated  in  this  manner. 
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B-5.  Application  Project  Proposal 


a.  Format 

(1)  Identification 

(a)  title  and  number  of  application 

(b)  submitting  agency 

(c)  MA 

(d)  RDA 

(e)  project  manager 

(f)  GtR  System  or  functional  area  supported 

(2)  Background 

(a)  applicable  directives 

(b)  general  background 

(3)  Application  Concept 

(a)  objectives 

(b)  scope 

( 4 )  Guidance  and  Reporting  System  Overview 
(if  appropriate) 

(5)  Functional  Description 

(a)  planned  products  and  services 

(b)  planned  inputs 

(c)  planned  data  flow 

<d)  performance  requirements 

(6)  Project  Plan 

(a)  project  plan 
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(b)  organization  and  responsibilities 


b.  Specific  Instructions.  The  following  instructions 
are  keyed  to  the  item  numbers  in  Figure  B-Sa. 

Item  1.  Identification.  Self-explanatory. 

Item  2.  Background 

Item  2a.  Applicable  Directives.  Enter  Army  directives 
supporting  requirement  for  application.  Include  regulations 
prescribing  GiR  Systems  to  be  supported. 

Item  2b.  General  Background.  Describe  events  leading 
to  recognition  of  need  to  develop  application. 

Item  3.  Application  Concept 

Item  3a.  Application  Objectives.  State  objectives 
of  application,  in  performance  terms  if  possible,  e.g., 
reduce  requisition  turn-around  time  to  less  than  four 
hours . 

Item  3b.  Scope .  State  scope  of  application; 

that  is,  state  information  functions  encompassed, 

e.g.,  all  civilian  manpower  management  functions  except 
daily  time  and  attendance  records  for  pay  purposes. 

I  tern  4 .  Guidance  and  Reporting  System  Overview . 

Brief  description  of  any  GfcR  Systems  supported,  showning  place 
and  role  of  application  proposed.  A  flowchart  with  explana¬ 
tion  will  be  included.  This  information  should  be  extracted 
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from  the  approved  G&R  System  Specification  (Item  4c) . 

Item  5.  Functional  Description 

Item  5a.  Planned  Products  and  Services.  What  the 
application  as  a  whole  is  to  produce;  relate  to  performance 
requirements.  List  major  outputs  of  the  system.  Include: 

.  reports,  periodic  and  unscheduled; 

.  files  maintained; 

.  other  services  provided,  for  instance,  handling 
of  ad  hoc  queries;  optional  features,  and  other 
significant  functions. 

Item  5b.  Planned  Inputs.  Enter: 

.  data  -  content,  format,  limits,  accuracy,  precision, 
media,  sources,  methods  of  collection,  and  mechani¬ 
zation; 

.  files  -  content,  format,  structure,  keys,  media;  and 
.  communications  -  media,  etc. 

Item  5c.  Planned  Data  Flow.  Flowcharts  showing  flow 
of  information  and  processing  logic  from  input  to  output  for 
the  application. 

Item  5d.  Performance  Requirements.  State  assumptions, 
constraints,  details  for  performance,  service,  and  functional 
goals.  Relate  to  GfcRSS.  Quantify  where  possible. 

Item  6.  Project  Plan 

Item  6a.  Project  Plan.  List  tasks  and  milestones  to 
be  accomplished,  specifying  end  products,  in  accordance  with 
Appendix  D.  Supplement  as  necessary  to  clearly  outline  plan. 
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Item  6b.  Organization  and  Responsibilities.  State 


which  organizations  and  individuals  are  responsible  for  ac¬ 
complishing  which  tasks,  show  overall  organization  structure, 
including  MA,  RDA ,  and  project  manager. 

B-6.  Application  Design  Specification 
a.  Format 

(1)  Identification 

(a)  title  and  number  of  OIS 

(b)  submitting  agency 

(c)  MA 

(d)  RDA 

(e)  project  manager 

(f)  Gl«R  System  or  functional  area  supported 

(2)  Background 

(a)  applicable  directives 

(b)  general  background 

(3)  System  Concept 

(a)  objectives  of  system 

(b)  scope 

(4)  G&R  System  Overview 

( 5 )  Functional  Description 

(a)  products  and  services 

(b)  planned  inputs 

(c)  planned  data  flow 

(d)  performance  rcguirements 


(6)  Revised  Project  Plan 

(7)  Technical  Specification 


(8)  Outline  of  Anticipated  Documentation  Package 

(9)  Communications 

(10)  Preliminary  Test  Design 

b.  The  following  instructions  are  keyed  to  the  item  num¬ 
bers  in  Figure  B-6a.  Items  1-6  are  extracted  from  the  ap¬ 
plication  project  proposal  and  modified  to  reflect  any 
changes  which  have  occurred  since  the  previous  submission. 

Item  7.  Technical  Specification.  List  here  the  equip¬ 
ment,  language,  organization,  interfacing  considerations, 
input/output  lists,  intermediate  results,  files,  operating 
procedures,  quality  controls,  and  error  procedures.  If 
ADPE  system  specification  is  required  in  accordance  with 
AR  18-2,  the  application  description  prepared  as  directed 
rn  .hk  18-2  paragraph  6300  -  6307  will  satisfy  this  requirerent. 

Item  8.  Outline  of  Anticipated  Documentation.  Package 
list  here  the  items  of  documentation  which  are  to  be  pro¬ 
vided  along  with  the  system;  provide  outlines  of  the  contents 
of  each.  Reference  Figure  B7  through  B9  for  minimum  contents. 

Item  9.  Communications ,  State  the  communications  methods, 
media,  volumes,  and  systems  which  are  to  be  employed.  Include 
interface  characteristics  for  use  with  other  systems. 

Item  10.  Preliminary  Test  Design.  Present  preliminax, 
design  for  testing,  validation,  and  acceptance  of  system. 
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B-7.  Application  Development  Documentation 

a.  General  Instruction.  The  application  development  docu 
mentation  is  to  be  prepared  as  directed  by  the  appropriate 
project  manager.  The  outline  below  represents  minimum  accept 
able  content  of  such  locally  prescribed  specifications. 

b.  Outline  -  Application  Specification 
Item  1.  Introduction  to  Application 

Item  2.  Application  Narrative  and  Process  Flow  Chart 
I tem  3 .  Input-Output  Data  Speci f ications  and  Sample 
Forms 

Item  4.  Data  Handling  and  Control  Procedures  in  Detail 
Item  5.  Error  Correction  Procedures 
Item  6.  Summary  of  Programs 
Item  7.  Master  File  Descriptions 

Item  8.  Table  Descriptions  (Internal  Tables)  Common  to 
Application 

Item  9.  Input,  Output,  and  Files  Grid  Chart 
Item  lo.  Storage  Allocations 
Item  11.  Revision  History 

c.  Outline  -  Program  Specification 

I tem  1 .  Introduction  to  Program,  Describing  Program 
Function 

Item  2.  Preliminary  Flow  Chart  and  Narrative,  Showing 


Interfaces  with  Other  Programs 


Item  2.  Preliminary  Flow  Chart  and  Narrative,  Showing 
Interfaces  with  Other  Programs 


Item  3.  Program  Logic 

Item  4.  File  Descriptors  for  All  Except  Working  Files 
Internal  to  Programs 
Item  5.  Layouts  of  Forms  and  Reports 

d.  Application  and  Program  Documentation.  Application 
and  program  documentation  consists  of  application  specifi¬ 
cations  and  program  specifications  as  updated  during 
programming  and  testing,  with  the  following  outputs  of  the 
programming  process  added. 

I tern  1 .  Source  Language  Listing  and  Machine  Code 
Listing 

Item  2.  Memory  Layout 
Item  3.  Sample  Printouts 
Item  4.  Test  Data  and  Results 

I tern  5 .  Description  of  Internal  Program  Tables 
Item  6.  Motes,  Comments,  Cautions,  etc. 

Item  7.  Operating  Instructions 

(a)  application  segment  chart,  show i no 
relationship  of  program  to  other 
programs 

( b >  operating  instructions  {call 

messages,  tape  mounting  instruc¬ 
tions,  control  carvis,  form  setup, 
etc. ) 
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(c)  normal  halt  list  and  restart  pro¬ 
cedures  plus  error  halt  list  and 
restart  procedures 

(d)  data  disposition  instructions 

B-8.  Test  Record 

a.  Contents .  The  test  record  will  consist  of 

(1)  Test  Procedure  Description.  A  description  of 
the  testing  procedure,  summarizing  the  original  test  plan, 
identifying  critical  testing  points,  and  indicating  any 
variations  from  the  anticipated  result. 

(2)  Test  Log.  A  detailed  chronological  record  of 
the  test,  showing  starts,  stops,  errors  discovered, 
corrective  action  taken,  and  other  operational  occurrences. 
This  log  should  be  maintained  during  the  actual  test 
period,  at  the  testing  site  ot  sites. 

(3)  Test  Data  Sets.  A  complete  set  of  test  data 
used  for  input,  in  hard  copy  form,  together  with  all  outputs, 
also  in  hard  copy. 

(4)  Test  bvaluation  Summary.  A  brief  evaluation  <  f 
the  test,  together  with  identification  of  anticipated  prob¬ 
lems  in  further  testing  or  in  system  operation. 


B-9 .  Implementation  Package 

a.  Content .  The  implementation  package  consists  of 
the  following: 
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(1)  complete  system  documentation,  including  appli¬ 
cation  and  program  documentation.  At  the  discretion  of  the 
MA,  certain  program  listings  may  be  omitted. 

(2)  separate  operating  instructions. 

(3)  identification  of  points  of  contact  for  inquiries, 
change  proposals,  etc. 

(4)  a  complete  set  of  test  data  and  results,  together 
with  instructions  for  conducting  a  local  system  test  to  as¬ 
sure  correct  local  implementation. 

(5)  guidance  for  transition  and  production  start  up. 
B-10.  Application  Project  Directive 

a .  Content 

(1)  Identification.  Identify  application  by  title, 
number,  classification,  and  other  related  identifying  infor¬ 
mation. 

(2)  Responsibilities .  Identify  or  assign  responsi¬ 
bilities,  roles,  and  tasks  within  life  cycle. 

(3)  Design  Criteria.  Specify  design  and  development 
parameters;  identify  systems  with  which  the  designated  appli¬ 
cation  must  be  compatible;  identify  legal,  policy  or  pro¬ 
cedural  constraints;  state  special  characteristics  such  as 
response  times;  direct  the  use  of  specific  programming  lan¬ 
guages,  standard  data  elements  and  codes,  source  data  automa¬ 
tion  and  other  technical  design  features  as  appropriate. 

(4)  Scheduled  Actions  and  Time-Phasing.  List  task 
accomplishment  and  resource  schedules. 
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(5)  Special  Instructions,  Include  pertinent  special 
instructions  on  further  reviews  required  by  HQDA;  resource 
identification;  and  the  form,  content,  and  frequency  of 
progress  reports. 
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APPENDIX  C 


CHANGE  PROCEDURE 


This  appendix  specifies  a  basic  procedure  for  coor¬ 
dination  and  control  of  changes  to  Management  Information 
Systems . 

C-l .  General 

Changes  to  Operational  G&R  Systems  and  Applications 
are  considered  for  control  purposes  to  be  of  two  primary 
categories:  Minor  Changes,  and  Major  Changes.  The  cate¬ 

gory  of  Minor  Changes  includes  all  corrections  to  remedy 
program  deficiencies,  and  other  changes  to  procedures 
which  do  not  affect  information  contents  of  a  Guidance  and 
Reporting  System;  provided  resources  required  fox 
developing  such  changes  are  capable  of  being  absorbed  with¬ 
in  the  normal  operational  capabilities  of  the  responsible 
organization  c  resources  have  been  specifically  allocated 
for  changes  and  modifications  and  do  not  exceed  six  man- 
months  of  effort.  Other  modifications  are  to  be  considered 
Major  Chances,  subject  to  Life  Cycle  Management  Requirements, 
beginning  with  the  Letter  of  Intent  IAW  paragraph  3-2; 
although  OAVCofSA  may  grant  exemption  from  later  life  cycle 
procedural  requirements  in  the  event  the  change  is  capable 
of  being  implemented  within  the  Minor  Change  Procedure. 
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The  Change  Procedure  will  therefore  operate  in  the  follow¬ 
ing  manner: 

C-2.  Change  Proposal. 

In  the  operations  phase,  the  procedure  for  chang¬ 
ing  an  application  or  G&P.  System  will  begin  with  prepara¬ 
tion  of  a  change  proposal  form.  The  oroponent  of  a  change 
will  fill  out  the  change  proposal  form  shown  in  Figure  C-l 
as  follows: 

Block  1  -  enter  system  title 
Block  3  -  enter  date 

Block  4  -  enter  proponent's  name  and  organization 
Block  5  -  describe  change  being  proposed 
Block  6  -  describe  justification  for  change 
The  form  will  be  submitted  to  the  appropriate  system 
manager  or  application  manager.  The  system/application 
manager  will  ente-  the  change  proposal  number  in  Block  2, 
and  will  review  the  proposal. 

If  the  change  is  clearly  to  be  considered  a  Minor 
Change,  he  will  determine  or  approve  changes  to  programs 
or  procedures  to  be  made,  and  insure  that  the  change  is 
coordinated  with  other  related  G«R  System  managers  and  appli¬ 
cation  managers  as  appropriate.  He  will  then  publish  or 
otherwise  promulgate  the  necessary  change. 
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If  the  ci.ange  is  a  Major  Change,  or  if  its  status  is 
questionable,  the  manager  will  prepare  and  submit  a 
Letter  of  Intent  IAW  paragraph  3-2. 

C-3.  Developmental  Changes 

The  project  manager  is  responsible  for  providing 
formal  control  over  changes  during  the  development  segment. 
His  procedures  must  insure  design  and  system  integrity. 

The  change  proposal  form  (Figure  C*l)  may  be  used  for 
project  change  purposes,  at  the  discretion  of  the  project 
manager . 
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CHANGE  PROPOSAL 


System  Name 


2.  Change  Number  _  3.  Date: 


4.  Proponent  of  Change: 


5.  Change  Description: 


6.  Justification  for  Change; 


FIGURE  C-l 
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PROJECT  PLANNING  AND  PROGRESS  REPORTING 

D-l.  General 

In  accordance  with  paragraph  3-4a,  a  detailed  plan 
for  the  application  development  is  submitted  with  the 
application  project  proposal.  Thereafter  it  is  revised 
as  necessary,  and  progress  reported  concurrent  w ith  the 
submission  of  each  document  prescribed  in  paragraphs 
3-4b  -  3-4e,  or  as  otherwise  directed  by  the  MA.  The 
basic  format  of  the  planning  document  and  progress  report 
(same  form)  is  shown  at  Figure  D.l.  This  will  be  supple¬ 
mented  as  deemed  appropriate  by  the  RDA  or  as  directed 
by  the  MA. 

D-2 .  Milestones 

The  completion  of  each  required  document  IAW  paragraph 
3-4a  -  3-4e  constitutes  a  project  milestone.  Where  the 
project  is  to  develop  several  applications,  such  as  a 
data  processing  system  or  a  set  of  standard  applications, 
a  milestone  will  be  scheduled  for  the  completion  of  each 
document  for  each  application  for  planning  and  for  report¬ 
ing  purposes. 

D-3.  Explanation  of  Figure  D.l 

The  Project  Plan  and  Progress  Report  shown  at 
Figure  D.l  will  be  prepared  as  follows: 
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Proiect  Description 


PROJECT  PLAN  AND  PROGRESS  REPORT 


1.  Project  Title  _ 

4.  In-House  . 
Man-Years 

6.  MA  — — — 
Resource  Status 


2.  Year 


5.  Contract  Cost 


7.  RDA 


3.  Quarter 


8.  PM 


9.  Actually  Expended  To  Date  j 
11.  Variance  Between  Blocks  4,  9,  and  10 


Estimated  Cost 
To  Complete 
S  I  KY^ 


Schedule  and  Status 


KSfiaHHtt 

UBBH 


Problem  Analysis: 


Calendar  Dates 


FIGURE  D.l 
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a.  Under  the  project  description  section,  the  follow¬ 
ing  information  will  be  entered  in  the  appropriate  block: 

(1)  project  title 

(2)  calendar  year  (of  report) 

(3)  quarter  (of  report) 

(4)  total  planned  in-house  man-years 

(5)  planned  total  dollar  cost  of  contracts 

(6)  monitoring  agency 

(7)  responsible  development  agency 

(3)  project  manager  in  charge  of  the  project 

b.  In  the  resource  status  section,  planned  and 
actual  resource  information  will  be  portrayed  graphically 
and  in  tabular  form.  A  cashed  line  will  graphically  por¬ 
tray  the  planned  resource  expenditures  by  quarter  for  the 
life  of  the  project.  The  actual  resource  expenditures 
will  be  shown  on  the  same  scale,  as  a  solid  line.  Tabular 
information  will  be  summarized  in  the  blocks  in  man-years 
and  contract  dollars. 

c.  In  the  schedule  status  section,  the  project  mile¬ 
stones  will  be  portrayed  in  terms  of  planned  date,  latest 
estimates  and  actual  completion;  using  triangles,  dotted 
triangles,  and  solid  triangles  respectively. 

d.  The  problem  analysis  section  will  provide  a  brief 
description  of  major  problems  affecting  cost,  schedule,  or 


D.65 


/*  .•if  .  n  A  /#•  'A1  **  \  i  i‘ 


performance  of  the  project  and  action  taken  or  needed  to 
resolve  them.  It  will  also  identify  any  milestones,  for 
which  the  estimated  completion  dates  have  changed  since 
the  last  submission  of  a  progress  report. 
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